This could be done (relatively) safely, but you have to watch out for a few things.
First, you should make sure nobody can access the token from another person easily (doh!). This is harder to do in practice than it seems. For instance, if you are emailing the token in plain text (which you will), you are basically passing the token from smtp server to smtp server you have no control over. EDIT: but the same would also hold for one-time tokens. Using SSL on your server is also a good idea, as that will encrypt the request headers that include the secret string.
Secondly, you should make sure the key is long enough for brute force attacks to take too long. If you combine this with brute-force-detection on your server (the hiawatha webserver can do this out of the box) you should be pretty safe against these.
Third, make sure the key is random! If you are using microtime, this means that an attacker can make an educated guess on the registration time of the victim (most websites have some sort of "registered at" feature), and just test all hashes from timestamps around that time. This reduces the number of hashes to test (for a single, targeted user!) from impractically large to just one million. That might seem a lot, but with one PC, and a 100ms response time this only takes a day. Remember, this is a targeted attack, which makes this very dangerous.
Another option you might implement is to use both the hash of the username, and the access hash in the URL. This way targeting every user at once is not possible.
IMO, when these things are taken into account, getting a token based login can be safer than a "regular" login, where people choose bad passwords and write them down on pieces of paper on their desk.