You're basically going in the right direction, but I'll point out some things to think about:
The default number of iterations of the PBKDF2 method may not be sufficient, and you may not want to leave things to the default. I would recommend specifying an iteration count of at least 10K.
On the other hand, the key size and salt size are counted by this implementation in bytes. 64 bytes is a bit too much. Keeping both to 16 bytes each should be ample. It's not recommended to go over 20 bytes as that's the maximum size of the underlying hash function / HMAC. Going over that will only give an advantage to the attacker (this, according to many, is a design mistake in PBKDF2). You may of course set the size of varbinary to a higher value to allow for future upgrades.
It's recommended that you keep a protocol number with your salt and hashed password. Doing so makes it possible for you to upgrade the scheme at a later date and per entry, when the user is available to reset his/her password.
Minor point; MSDN does not specify when the salt is generated. I would check the randomness of the salt (check if it is different each time) and only ask the salt after calling
getBytes
to make sure that the salt is indeed random, even if the implementation changes. Otherwise generate it yourself using a cryptographically secure random number generator.