A few things to clear up, first.

Background

We are mixing two different concepts a bit: the protocol and cipher suites. SSLv3 being the protocol, and forward secrecy being a trait of the negotiated cipher suite. Which cipher suites are selected depends on the client, the server, and the protocol that gets negotiated.

This means you cannot rely on the version of the protocol to decide whether or not the browser supports forward secrecy (this will probably change with TLS 1.3). SSLv3 (at least as a specification) does support some forward secrecy cipher suites, such as SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA (though in practice I don't see browsers supporting that cipher suite). That goes the same to say that a version of TLS does not mandate the use of forward secrecy.

Internet Explorer is an interesting case because it is the only major browser where the supported ciphers depends on the version of the browser and the version of Windows. This is because Internet Explorer defers all of the HTTPS negotiation and handling to a component of Windows called SChannel. In order for Internet Explorer to support a given protocol and cipher suite, SChannel needs to support it first. This makes it a little complex to say what cipher suites and protocols are supported.

There is one version of Internet Explorer that supports SSLv3, and nothing else, which is Internet Explorer 6. It remains the only browser that has a modicum of usage which does not support TLS 1.0 (that's not exactly true; IE6 does support it, it's just not enabled by default). So by going through the trouble of displaying an error page, the only browser you'd be targeting is Internet Explorer 6. I suppose other browser could disable support for all versions of TLS and leave only SSLv3 selected, but that would mean a large portion of HTTPS-enabled web sites would not work for them, as many have already completely disabled support for SSLv3. In practice, I don't think you will come across many browsers that support only SSLv3 and isn't IE 6. IE 8 on Windows XP comes with TLS 1.0 on by default, and any version of IE on Windows Vista or later supports at least TLS 1.0. Internet Explorer 11 on Windows 8 and Windows 7 support the (as of writing) latest TLS 1.2.

Showing a "Sorry, no SSLv3!" page: What could go wrong?

Getting a little closer to your question, your concern is showing a page to users whose browser wants to connect with SSLv3. There are pros and cons to this. The first, beware that SSLv3 has an issue with it called POODLE. The discovery of POODLE has let many web sites to completely shut off SSLv3 support.

This leads to a chicken-and-egg problem. If you were to redirect users based on the version of the protocol negotiated, your web server would need to support SSLv3 in the first place to detect the presence of it and serve a redirect. However doing so, you may be exposing those clients to unnecessary risk. If the server must accept the SSLv3 connect to show a page to the user that SSLv3 is not allowed, an active-attacker could use that as an opportunity to exploit the very weaknesses of SSLv3. For example, let's say a client authenticates to your website over HTTPS using TLS 1.0. IE doesn't support TLS_FALLBACK_SCSV, and an active attacker forces the browser down to SSLv3. If your site uses cookies to authenticate, the attacker has now forced the browser down to SSLv3 (which will serve your error redirect) but it could reveal the authentication cookie. Remember that once the user has their authentication cookie, browsers send those cookies along with every request. Stealing an authentication cookie is a big deal, and entirely possible in this scenario and using POODLE. So even though you are attempting to just some a simple error page, there is risk associated with supporting SSLv3.

IIS can't do this on its own

So, to your actual question. No, Internet Information Services in itself cannot redirect a request based on the SSL/TLS version or cipher suite. There may be a 3rd party module that does it, but I am not aware of one. You have a few options, though.

Could fix at load balancer

You can offload the connection to a reverse proxy that does support redirecting based on the presence of SSLv3 - I'm not aware of a way to do this based on the actual cipher suite. HAProxy is one that I know of that can - there are probably others that I am just not familiar with. I won't go into the specifics, but with HAProxy you can assign an ACL based on the SSL version like so:

acl sslv3 ssl_fc_protocol SSLv3

Once you have the ACL, you can send them to a specific backend, or process it however you want.

Could fix with own IIS module

Other options might be finding or developing your own module for IIS that can do this. IMHO, IIS doesn't have magnificent support for configuring and supporting SSL. Personally, I'd offload the SSL onto a reverse proxy, but I know that isn't for everyone.

Could fix with just disabling protocol support below TLS 1.0

Your third option is to just support only forward secrecy cipher suites and at minimum TLS 1.0. Using a cipher suite of AES128+EECDH:AES128+EDH with TLSv1, TLSv1.1, and TLSv1.2 will get your support for most browsers. The only browsers that would be left out in the cold is any Internet Explorer version on Windows XP since Windows XP doesn't support any reasonable cipher suite that supports forward secrecy. As far as I know, Windows XP only supports DHE with DSS, which is something you absolutely don't want to bother supporting.

My way: disabled SSL protocol support

The latter is the solution I have gone with. Supporting deprecated protocols and cipher suites poses a risk - even if they are there only to show an error page.