The certificate request is generated where the private key is generated; and the private key should, normally, be generated by the client, since the client will ultimately store it.
You can have a model where you (as a server) generate keys for clients and then distribute the keys and certificates to the clients, but it raises the question of why you use client certificates in the first place: certificates are for situations where the prover (the client, who wants to be authenticated) demonstrate his identity to the verifier (the server) without giving enough information to the verifier to allow it to impersonate the prover afterwards when talking to a third party. In a classic client/server setup, this is overkill; and this extra property disappears if the server itself knows the private keys (even transiently).
Moreover, the third-party CA will bleed you dry by billing you for each client certificate. Using a third-party CA for a purely private business (the client certificates are for you, not for anybody else) looks like wasted money. For the server certificate, this is understandable: you want a certificate that every potential client will recognize as valid, i.e. relative to a root CA certificate that they already have. But in the other direction, this is just your own server. Running your own CA (e.g. with EJBCA) would probably be worth the effort.
Assuming that using client certificate is an unavoidable characteristic of the situation at hand (e.g. some high-ranking manager has heard the term "certificate" and fell in love with it), then you can produce them on the server side by talking to DigiCert (or your own CA, if you run one) with whatever method is appropriate for them. On a Windows system, private key generation, certificate request building, and acceptance of the resulting certificate, can be done with the command-line tool certreq. Once you have the private key (it never left your machine) and the certificate, export them both as a PKCS#12 archive (also called "PFX"), protected by a password, and send that to the client, who will import them in his browser. This transfer ought to occur with some protection, of course... though a PKCS#12 archive is tolerably well protected by the password, you still have to transfer that password to the user in some way.
