Generating the hash would not be much of an issue as rand() is not random enough.
For the random key generator, if you're on linux/unix, you could get the values from /dev/urandom instead of rand() which would be good enough for your usecase.
And yes, by submitting a valid hash that gets an account validated, you would be able to deduce one's email address(at that time, your application would probably show the email address or the username of the user at the validation page which would somewhat do the same thing).
However, despite that the emails can be retrieved via this way, I would say that it is not really much of an issue as you can deduce it as well via the login page or forgot password page if your application does not cater for such conditions. Another point would be that, after the user is validated, the validation link should be dropped from your database so the attacker cannot will not be able to deduce the email for that email account anymore. Hence, the email accounts that could be deduced would be the ones that are not active(as the account is not validated yet) or new accounts. And still, it doesn't have much impact as gaining one's email address alone will not do you much.
A bit offtopic, but I feel the need to say this since it is somewhat related.
That aside, getting the attackers to validate your user's account or getting the user's email address is not really much of an issue, however, if you allow the user to login directly after validating their account, then the attacker would be able to gain access to the user's account which is bad(which is somewhat common as well, unfortunately).
Hence, the proper way would be to only validate the user's account upon activation and not letting the user to login directly into their account.