Another attack vector to consider is Session Hijacking. Assuming you're using Post-Redirect-Get (which you should be in general), you'd have to save the password in the session in order to resend it via GET. While the session itself is in a relatively secure, trusted place (on your server), storing plain text or reversably encrypted passwords there makes your session store an even bigger target. But let's say that's what you do.
Say an attacker obtains or engineers the user's session variable. The user enters the password but fails the form. Whoever issues a GET request with that session variable (which could be the attacker) is handed the password in the clear. This is worse than a standard session hijacking, because a standard hijacking would only allow the attacker to impersonate the user, not obtain passwords that might be valid for other sites.
Of course, you can mitigate this by any standard session hijacking defenses -- regenerating the token on load, or simply rendering on post instead to avoid the session entirely. (Please don't do that. Having the browser bug me when I reopen or reload a page is frustrating, especially since I do it a lot thanks to no-script.)
The fewer places the password exists, the fewer targets for attack. If you must do this feature, either go with Andre's comment suggestion to remove the password field entirely with a button to change it, or fill the password field with a standard, but invalid password (ie, less than your minimum length) that you can check for when you've stored a password. Just don't send real passwords, even over HTTPS.