Well, no, there's no defined TLS ciphersuite that does the RC4 algorithm with a discard of the original stream.
I'm not a designer of TLS, nor am I a member of the IETF working group that controls it; I suspect that they'd prefer for people to transition to ciphersuites that use AES (or some other newer cipher), and so there's little incentive for them to add variant RC4 ciphersuites.
As for the problems that the know biases that the start of the RC4 stream can cause, well, those biases actually come in two flavors:
There are known biases in the keystream bytes themselves; for example, the second byte of the keystream is 0 with probability 1/128 (rather than the expected 1/256). What this means is if you have a few thousand TLS sessions keyed with RC4, and you know that their plaintexts have the first few bytes in common, you might be able to deduce the values of the second plaintext byte; with more keystreams, you might be able to deduce the values of the first and third plaintext bytes. Obviously, this is a security failure, and this may be of real concern if (for example) you're sending a password through the TLS session as the very first thing.
There are known correlations between the keystream bytes and the RC4 key itself. These correlations aren't strong, and so you'd need thousands of keystreams from related keys to get much information about the key. This is exactly the problem that WEP ran into; however, with TLS, they derive the RC4 key from a real key derivation function; that means that there are no known corrections between the keys from different connections, and so this observation is of no use.
The bottom line: if the first few bytes of the TLS stream are high-value, you probably shouldn't be using an RC4 ciphersuite.