Is this a sensible cryptographic protocol intending to reduce the impact of compromised security?
I don't think the approach you sketched helps very much.  If the server is compromised, the attacker can pretty easily modify the server-side software to log and record all the cryptographic keys, and then you haven't gained anything.  Therefore, I don't think the approach you sketch is likely to be a great way to spend your limited software development budget.

If you want to mitigate the risks of server compromise, let me suggest two alternative approaches that I think might actually be worth your time:


Privilege separation. Rather than have one server that does everything, split it up into two servers.  One server does just the crypto decryption, and the other does all of the other application functionality.  Install these on two separate servers, with separate passwords etc. so that if the latter is compromised, it won't compromise the former.  The former server is super security-sensitive, but if you also keep its functionality very simple and if you administer it carefully, you may be able to reduce the likelihood of compromise of that server.
Client-side cryptography. Don't ever allow the keys to be on the server.  Do all of the encryption purely on the client side.  The client generates the cryptographic keys, and never allows the secret key to leave the client (never shares it with the server); encryption or decryption with the private key is done entirely on the client side (not by the server).  However, it takes additional work to make this work, and make it secure, and address the resulting key management and usability challenges, so this is not a no-brainer: it comes with some non-trivial disadvantages.