No, you're solving the wrong problem.
Moving from SHA-1 or SHA-256 to SHA-512 doesn't make cracking the hash significantly harder. Hashes generally aren't reversed by means of some mathematical property of the algorithm, so advancing the algorithm doesn't changing the security very much.
Instead, hashes are brute-forced using a "guess and check" technique. You guess a password, compute the hash, and then check to see if you guessed correctly. And repeat, and repeat, and repeat until you finally get it.
So the way to slow down the attacker is to slow down the hashing process. If it takes longer to check each single password, then the attacker can't guess as many of them. And in this case, SHA-512 isn't appreciably slower than SHA-256 or SHA-1 or MD5. So you're not really adding any security.
Instead, the common thread between techniques like bcrypt, PBKDF2, and scrypt, is that they all run the hashing function over and over and over, thousands of times for just one single password guess. So say a site uses PBKDF2 at 10,000 iterates: this means that the attacker has to expend as much time and resources on a single guess as he otherwise would have to on an entire dictionary of 10,000 passwords. By slowing the attacker, you limit the number of passwords he ultimately can guess, and therefore decrease the likelihood of him eventually guessing correctly.
Many installations tailor their configuration to fit existing hardware. So for example, LUKS uses a minimum of 1000 iterations, or however many it takes to consume 1/8th of a second, whichever is longer.