In almost all cases imaginable, I would just let them receive the SSL handshake error. Their own problem.
I like your creative idea, but that comes with a cost - a new vector of communication has to be established with pen-testers and auditors. They must be informed about the solution you're using. A typical auditor would just look at the results of a vulnerability scanner and say that you received grade F - your site is not secured. Even if all you're trying to do is present a customer-friendly message that a typical web-browser fails to deliver (a generic SSL handshake error doesn't tell much)
Even if you manage to communicate to auditors and pen-testers, the general public may put the blame on institution. Not a problem for smaller enterprises. A big risk for reputable companies. A very similar solution was implemented in a financial services company for SSLv3 users. Just one week later, the bank ended up in news because 'apparently the web site is not secured'. The vast majority of journalists are eager to publish junk articles without doing any research.
Since banks already are obliged by regulation to refrain SSLv3 users (and soon will be obliged by PCI DSS 3.1 to refrain TLSv1.0 users), I would not worry much. The general public wants to use Internet Banking and PayPal, therefore, they will sooner or later upgrade their browsers anyway. My recommendation is just to stay on the same page with Internet banking websites and PayPal. Going any further with restrictions is not advised (i.e disabling TLSv1.1 is a common mistake these days). I would not go that far.
Nacreous
