This is absolutely silly. I can't see why anyone, let alone NIST, would want this. They should know better:
- SHA-512 is only faster than SHA-256 in pure x86-64 versus x86; add SSE to the mix and start doing four SHA-256 blocks in parallel, and SHA-512 is about the same speed, or slower!
- SHA-256 is not particularly slow, overall: 150MB/s is quite possible with it. Half the speed of SHA-1, yes, but still not bad. That is gigabit on one core, and more than the sustained read speed of a hard disk (although not an SSD).
- Of the five SHA-3 finalists, really only JH is slower than SHA-256 in x86, or SHA-512 in x86-64, maybe that's a bad implementation; most of the other candidates run around twice as fast as SHA-512 at its fastest (i.e. not too far off SHA-1 speed, and some of them can be parallelised so can run much faster), especially in 64-bit. They can probably be made to run faster.
- The SHA-3 winner (Advanced Hash Standard?) will be announced next year - and will at that time already have faster, more secure drop-in replacements for SHA-224, SHA-256, SHA-384, and SHA-512 (and anyone using SHA-1 or, God forbid, MD5 will need a stern talking-to).
Why, then, would we want a kludge for more speed - in such a limited scenario - when an established, relatively well-analysed hash exists right now and can go at the same speed, and in a year or so, it will then be near-instantly obsoleted by a faster, better-designed hash function?