So far as what happens when the user clicks on the URL in the email, I think it's so simple it many never have been thought to make into a module. Your solution works fine, although here's how I tend to implement it:

I create a "temp" table, separate from the user table. Populate said table with the password the user chose, the one-off id field for the new user that's in the URL you emailed, and that user's ID in the "real" user's field (and, possibly, a timestamp). When your app sees the URL, it queries the "temp" table, and simply loads the real password into the correct row of the user table, and then deletes that entry in the temp table.

This provides you with an extra layer of security, and a way of cleaning up "false setups" without touching your user table (daily cron job to clean out x days old entries in "temp" column). It also means one less column to "drag" around for the user table; if it's queried often, lightweight is best, esp. if a field/column's to be used once.

Make sense?