Yes, but there are potentially far reaching consequences. I'm going to answer your question more generally.
The simple answer is to revoke the signing key. As easy as that answer is for a user key, there are still issues. For example, is everyone who might rely on that signature subscribed to and updating based on our CRL? If not, revoking the key has no real effect.
If we were to reframe it just a bit, though, and talk about a code signing or certificate signing key, the problem is bigger. You can still "simply" revoke the key... but the impact is that everyone who references our CRL will no longer trust anything signed by that signing key! As you can imagine, this will lead to a significant amount of work to resign everything.
How you revoke the key will depend, of course, on the specific package that you are using. It typically involves populating data about the compromised key into a certificate revocation list which must then be circulated to all trusting entities.
How do you automatically migrate them to a new key? Well, if they have lost control of the key it's hard to imagine this as an automatic process; it really is more a reaction to an incident. For normal key changes, however, many products handle this automatically (Microsoft Certificate Services with autoenrollment, as an example, or with self-service certificate renewal) and with others it is pretty manual (PGP, OpenSSL) though you could certainly automate it to a degree.
The difficulty in building such a system from scratch is that, typically, you will prefer -not- to generate or store the private key for the certificate, especially for a user certificate; you would really like them to generate the private part of the key. This usually means that they will need to be involved somehow.