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).
The benefit of this is to know that if I choose to disable some specific cipher, which clients is it likely to affect, just like the SSL labs tests show for web clients.
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:
100.00% 600433 TOTAL
29.53% 177285 DHE-RSA-AES256-GCM-SHA384
21.20% 127304 ECDHE-RSA-AES128-GCM-SHA256
20.62% 123804 DHE-RSA-AES256-SHA
7.65% 45919 AES256-SHA
6.40% 38404 ECDHE-RSA-AES256-GCM-SHA384
4.42% 26558 AES256-GCM-SHA384
4.36% 26189 ECDHE-RSA-AES256-SHA384
1.76% 10586 AES128-SHA
1.17% 7003 RC4-SHA
0.93% 5577 DHE-RSA-AES256-SHA256
0.90% 5389 ECDHE-RSA-AES256-SHA
0.56% 3372 DHE-RSA-CAMELLIA256-SHA
0.19% 1137 RC4-MD5
0.08% 503 EDH-RSA-DES-CBC3-SHA
0.08% 454 DES-CBC3-SHA
0.07% 444 AES128-SHA256
0.04% 235 DHE-RSA-AES128-GCM-SHA256
0.01% 82 AES128-GCM-SHA256
0.01% 59 AES256-SHA256
0.01% 53 DHE-RSA-AES128-SHA
0.00% 23 ECDHE-RSA-AES128-SHA
0.00% 14 DHE-DSS-AES256-SHA
0.00% 11 ECDHE-RSA-AES128-SHA256
0.00% 10 ECDHE-RSA-RC4-SHA
0.00% 10 ECDHE-RSA-DES-CBC3-SHA
0.00% 4 DHE-DSS-AES256-GCM-SHA384
0.00% 2 CAMELLIA256-SHA
0.00% 1 DHE-RSA-SEED-SHA
0.00% 1 AECDH-DES-CBC3-SHA
Best Answer
It has nothing to do with IE6/XP. If you are still allowing SSLv3 or TLSv1.0 which is required to support IE6/XP, you are failing most test suites (including PCI compliance). Qualys has a page dedicated to their SSL Labs scoring system.
Regarding your ciphersuite string, adding !kRSA should do it. RSA key exchange does not provide forward secrecy.
I usually use the following.
Openssl documents the cipher parameters string.