This is an incorrect assumption, at least when I interview people. A live coding interview has (almost) nothing to do with the "quality" of your code, and doesn't necessarily even demand complete correctness. It's about observing your process, and trying to simulate what it would be like to work with you:
Do you approach a problem with caution until you're sure you understand it, or jump in head first and start writing code you hope is correct? Can you verbalize your thought process and communicate it to others? How good are you at reasoning about the runtime behavior and correctness of your solution? Do you consider edge cases and naturally want to test them? Things like that are won't show up in a take-home coding test, and tell me a huge amount about what kind of programmer you are, and whether I want to hire you.
See: http://www.yacoset.com/Home/signs-that-you-re-a-bad-programm... - there's a lot of truth to this article, and many of these flaws will be glaringly obvious in a live coding session.
And yes, of course some people interview poorly or are just having a bad day. That's unfortunate, but I'm not about to give up a powerful interview tool just because it can have false negatives. Until I find a divining rod that will point out the best programmer in a room, asking a candidate to write some code is the fastest way to learn what kind of programmer they actually are. (And also immediately weed out people who can't actually write real code.)