Ability to compute a lot of hashes very fast with dedicated hardware is a problem for password hashes, but not a new problem. Before the advent of ASIC specialized in SHA-256, we were already taking FPGA into account (see for instance this research machine, from already five years ago). An ASIC can roughly be clocked at two to three times the frequency of the equivalent FPGA; mass production further lowers costs. This does not qualitatively changes the situation, but it sure gives a boost to the attacker, something like, say, 3 bits or entropy.
Of course, a simple SHA-256 for password hashing is not a good idea; it is way too fast even when the attacker has "only" classic PC; I assume we are talking here about PBKDF2, a construction for slow hashing which relies on an underlying PRF, usually HMAC, which itself is built over a hash function such as SHA-256.
Theory already says that, all other things being equal, password hashing should use the underlying hash function that is most efficient on the hardware which will process it in the "honest system", i.e. a PC. That's the point of hashing functions such as bcrypt or scrypt. If you want to stick to PBKDF2, using SHA-512 would be a good idea, because SHA-512 uses a lot of 64-bit arithmetic operations, something which a modern PC is very good at, but which GPU suck at. ASIC specialized in SHA-256 do not change that recommendation.
