I was already wondering why you would need 2048 bits, because brute forcing a 512 bit output hash takes already a $2^{256}$ operations on average (w.r.t to collision resistance, due to the Birthday Paradox – preimage and second-preimage attacks take on average $2^{511}$ hashes), which is secure enough, for all kinds of hardware available today.
I assumed that you would probably want to transform the hash output into some form of key with a length of 2048 bits, your comment confirmed this. In that case, what you need is not necessarily a hash output of that length, but you need a secure Key Derivation Function (KDF) that allows "stretching" the random hash output to the desired size.
Have a look for example at the KDF described in NIST Special Publication 800-56A: “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography ” that describes how to stretch hash outputs to arbitrary sizes securely.
When equipped with such a KDF, it basically doesn't matter what hash function you are using (as long as it itself is secure) so you can safely use one of the sha-2 family hashes (SHA-256, 512 etc.).
One well-known hash function that I'm aware of is Keccak. You can find a public domain reference and optimized implementations on their website.
Its output size is variable and arbitrary, so you can just set it to 2048 bits. However, the authors only make security claims up to 1592 bits...
Others have already questioned this to some degree. I think I'll do a bit more of the same.
About the best you can hope to get from a hash is to "distill" entropy from the input. It can't, however, produce any more entropy than the input already contained (and will usually discard at least a little).
That means for a 2048-bit has to make any real sense, you need to provide it with an input that contains at least 2048 bits of entropy. As Shannon showed long ago, English text (for one example) typically contains about one bit of entropy per character. That means for your 2048-bit result to mean much (if anything) you need to give it roughly 2048 bytes of input. That's enough that for most practical purposes you can forget about memorizing it, so you pretty much need to start from a file -- but the minute you do that you've created a much greater security vulnerability.
Under most normal circumstances, you're probably going to get more security from a shorter hash. About the only way I can see this as being even potentially useful would be stored on something like a smart card. Even then it's pretty pointless, but at least it wouldn't necessarily be hurting your security, just wasting all your smart card space on a single "password" instead of the much greater number it could normally store.
One lesser-know hash function is ASH-2, which is based in the SHA-512 with a rearrangement in the data input and the use of some pepper to produce the final result.
I don't have an answer to your question beyond what emboss gave.
However, I have to ask: why do you think you need to do this? If you're using RC4, well, RC4 can take a shorter key; do you really think that RC4 with a 256 bit key would be insufficient for your needs? RC4 has known weaknesses (both with the initial bytes and the distinguishers); if you really security requirements that a $\ge$ 256 bit key is mandated (which I really doubt), then you probably don't want RC4 at all, but instead use a better cipher (which as AES-256).
Now, you might simply be looking for cheap overkill (that is, making part of the cryptographical system far stronger than needed); IMO, there's nothing really wrong with cheap overkill (as long as you understand that this doesn't actually make the system any more secure). On the other hand, the fact that you had to ask means that this overkill might not be as cheap for you as you were hoping.
