As I was working my way through this problem, I reset my app pool back to Network Service. Not only did I see that the processing was much faster, but the installation actually worked. I also reset the iis service... 

If this is truly the problem, then I have no idea what is causing all the fuss.

I just ran into this same issue...  I run on a shared IIS6.0 environment, so changing user permissions is not an option.  However i do have the luxury of direct contact with one of the sys admins for the cluster. 

This issue turned out to be an issue with the 05.01.00 update script attempting to (perhaps with a hard-coded file path) read/write to "C:\Windows\temp".  The windows installation of the server is not available to specific site instances; they use a different file i/o path entirely.  This was causing both the error, and the error to not be logged in the logfile, since DNN doesn't appear to be checking for an error on the event of reaching the temp directory.  This would explain why people changing back to running under Network Service would appear to 'correct' the issue -> because the temp dir on the OS install is now available, where it previously wasn't on the specific user.  

What does not make sense, is why only that particular DB update script attempted to access the windows temp dir, and the others did not (or used temp dirs created on the fly in their own partitions).

Hope that helps.