not so fast. The risk is not, in fact, about collisions. It more is about second preimages.
A collision is when someone can find two distinct inputs for a hash function, such that they hash to the same value. The attacker has control over both inputs. In your case, the attacker would compute two specially crafted email addresses, then register both, and, at a later time, would be able to get data from one account sent to the address of the other. It would not buy anything to the attacker: he already owns both accounts.
A second preimage is when the attacker is shown an input, and is challenged with finding another one which hashes to the same value. This is not the same setup as a collision attack: that time, the attacker has control over only one of the inputs, not both. This makes it more difficult. This maps to your situation: the attacker wants to register an email address which hashes to the same value as the target account's email address, so that the attacker may claim forgetfulness for that target account, and get user name and password reset link mailed back to his address.
If you use a decent hash function, then collisions are not to be feared since they are utterly improbable; and second preimages are even a lot less feasible. For a strong hash function with an output of n bits, cost for finding a collision (combining luck and raw power) is 2n/2 and that's already technologically infeasible if n ≥ 200 or so; for second-preimages, the cost rises to 2n, billions of billions of times higher. See this answer for more on the improbability of collisions.
As you state, you will want your hash function to be a password-hashing function (i.e. something like bcrypt, with salts and many iteration) in order to thwart a completely different kind of attack, i.e. an attacker stealing the email hashes and cracking them to be able to spam them. It must be noted that a given function may theoretically be deemed a "good password hashing function" (i.e. secure when it comes to storing password hashes) without actually be resistant to collisions or even second-preimages. Requirements for password hashing don't include all requirements for secure hashing.
A prime example is PBKDF2: as far as password hashing functions go, it is considered reasonably decent. However, it is not resistant to collisions (this is due to the fact that it uses HMAC and HMAC uses a key K which, in PBKDF2, is the password; and when the length of K exceeds that of the "block length" of the underlying hash function, then K is replaced with h(K); so a big K yields the exact same output as h(K)). Fortunately, you don't mind collisions; you just need resistance to second-preimages, and PBKDF2 will be fine.
This point illustrates the need to use precise terminology when dealing with cryptography. If you did not understand the details, then this illustrates it even more: cryptography is subtle.
Summary: use bcrypt or PBKDF2, and the risk you are fearing is non-existent. It won't happen in practice; attackers won't be able to force it. You should not worry about it, because there are other "risks" which are billions of billions of time more probable, and that you don't worry about (or go buy a shotgun !).
As a side note, you will want to normalize email addresses (e.g. force lowercase) before hashing, because at least parts of an email address is case insensitive, and you cannot expect users to always use the same casing for their own email address.
As another side note, since bcrypt/PBKDF2 are expensive functions, you will want to hash a submitted email address only once -- meaning that you must know what salt to use; you cannot afford to hash it one thousand times if you have one thousand stored email addresses. Therefore, one has to assume that the user who forgot his password actually remembers his user name, so that your server will compute the proper hash with the correct salt. This is the assumption I have used above.
Alternatively, don't use salted hashing, so that you may hash the email address generically, and use the resulting hash value as index in your database. However, this weakens the resistance of your hashes against the second attack type: when an attacker manages to steal a copy of your database (SQL injection, lost backup tape...), then he will find it easier to "reverse" the hashes and recover the email addresses. You have to choose your poison...
In that email-hash-as-index case, you again have to worry about collisions, because an attacker finding a collision would be able to force a situation where your server is trying to record an email-hash-indexed entry and finds an existing entry with the same hash -- depending on how you implement it, this may or may not be a problem. In fact, the "shared salt" model implies that password hashing functions are not a good fit. We are back to the "crypto design" phase and this requires a lot more thought. If you really want to go that road then you can expect difficulties.
(As a starting point, I would envision a custom nested hash as h(h(h(...h(email)...))) with h = SHA-256, and some thousands or millions of iterations, but a lot more thinking time would be needed before deploying it in production.)
