You are right that ECC in RedHat's (and therefore in CentOS's) openssl is disabled, due to patent concerns; see (eg) this bugzilla entry for more details. Note how any time anyone opens a new tracker to compain, it's closed as a duplicate of this one, so don't be fooled by the age of the tracker into thinking that it's a lapsed problem (side note: although most of that bugzilla is bad news, I did like RH's comment 'Please note: "Ubuntu does it" is never a viable legal argument.').
You have correctly divined that getting round that will mean compiling your own openssl, which is good. But having done so, you can't simply install packaged binaries and expect them to magically pick up your new libraries, because they won't.
You'll need to recompile openssl, with eg --prefix=/usr/local/openssl-custom, then make install it to that new location, then compile nginx from source taking care to tell it to compile and link against the new libraries (I can't give you a standard incantation for that, because it varies from package to package, but -with-ssl=/usr/local/openssl-custom can sometimes be the right thing).
If you need any other tools to work with nginx, and any of those have openssl dependencies (and these days, what doesn't?), you will likely need to compile those, also.
Please let me end by discouraging you from this. It's a lot of work; the compilation is the least of it, you then have to stay on top of all new releases of the packages you're built, and rebuild them whenever they change. I don't know why you've decided you need Forward Secrecy, but I strongly suspect that you will cause yourself more security issues by packages getting out-of-patch than you will ever fix by enabling it.
Note also comments 43 and 90 in the bugzilla entry linked above; if by Forward Secrecy, you mean Perfect Forward Secrecy (PFS), then enabling PFS does not seem to require having ECC. Or just wait, since it looks like we're getting ECC as of RHEL6.5 (C6.5).
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.
Best Answer
You don't need to restrict yourself to a specific cipher, but instead simply enable all ciphers which are acceptable to you and in the order you prefer them. The resulting cipher then will be negotiated between client and server depending on the supported ciphers on both sites. Don't restrict yourself unnecessary.
As for the ciphers typically used at the server side you might have a look at Quantifying the quality of TLS support where I've analyzed the TLS support for SMTP from the top 1M sites according to Alexa, which are about 600000 mail server with TLS enabled. According to my tests about 33% of the servers use ECDHE ciphers and 52% DHE ciphers, so that 85% use forward secrecy.
And for some more information about the ciphers used you will not find in the study here is a detailed list of ciphers negotiated when used with the DEFAULT cipher set of OpenSSL 1.0.1: