Using the GUID as unique identifier for the user instead of the email address has benefits against low-power attackers. The URL-with-GUID has been sent through email, so it cannot be considered as really secret. Motivated attackers will spy on the network lines and see that email. However, amateurs or automated attack bots, while not being able to read other people's emails, may "guess" email addresses, but not random GUID.
The GUID has thus any relation with security only insofar as it is unpredictable, and then it would bring any good only against attackers who are not very powerful. Using the GUID does not harm, but don't believe that it really adds much protection. You might want to make sure that the GUID is generated wit the version 4 algorithm, i.e. 122 bits from a strong PRNG: though GUID aim at uniqueness, you want unpredictability, which is another beast; version 4 GUID ensure both.
Keeping in mind that the GUID is not (really) secret, your system can be described as such: there is a one-time registration password, which is a four-digit PIN. After registration, a normal user-chosen password is used.
The main problem is that the four-digit PIN is too easy to guess: an attacker only has, on average, to try 5000 of them before hitting the right one. You can mitigate this problem by deactivating the PIN code after, say, three wrong attempts for a given GUID; that's the model of smart cards, with your server as the card. However, this will thwart only attackers who do an online brute force.
It unfortunately happens, occasionally, that some attackers obtain a glimpse at some parts of the server database. This is a frequent result of SQL injection attacks, for instance. Discarded old hard disks are also a classic source of such leaks. This is the very reason why you envision storing not passwords of PIN codes, but only hashed versions thereof.
But password hashing, even if done properly, only slows down attackers. If the iteration count is set so high that it takes a full ten seconds of computing for your server to verify a PIN code (and ten seconds are a very long time for a waiting customer), and attacker will "just" need 50000 seconds worth of computation, with the same hardware, to "try" 5000 possible PIN codes. Since the attacker will throw in a couple of multi-core PC, he will probably get down within an hour or two. That's not a lot.
I advise using a longer PIN code, say 8 digits.
To sum up: your GUID is not "secret enough" to tolerate a four-digit PIN, even for a one-time registration page. Using a GUID instead of the email address is interesting and you want it to be as discreet as possible (so use "v4" GUID), but even so, four digits are not enough for a PIN when the verifying system is not a tamper-resistant smart card. Use eight digits (or more). Since the user will type the PIN code only once, he can tolerate a rather long sequence (Microsoft could make users type 25-letter activation keys, so I don't think that 8 digits for registration would be too much to ask).