uniqid() does not create a cryptographically secure hash, and sending sensitive data over plaintext channels such as email or http means that anyone in between can read them.
Is this a problem? No, not really (with the exception stated in the last paragraph).
The information you send out consists of the user's email address and a confirmation key. This is also what's stored in the database. There is no way of sending an email without revealing the recipient's email address, so transmitting that address in plaintext as part of an URL is no problem either. If some Great Evil is going to happen, then it has already happened.
Now what about the confirmation key?
You could be giving out consecutive integers as confirmation keys (actually
uniqid() is not very far from that!), and it would not matter. A malicious person could intercept someone else's key or they could trivially generate their own, but neither is going to allow them to register a fake account, since your database query looks for the pair <username, confirm_key>. A stolen or random/fake/calculated confirmation key thus does not work for another (random) username, it is worthless for an attacker.
The only attack that is reasonably plausible is that someone could intercept your email and confirm your legitimate account with the correct email address and confirmation key before you are able to do so.
This is indeed a problem if your system is designed so that confirming a user account automatically logs you into your first session, too (some sites do just that!).