There's a fine line between trying to suss out whether or not a programmer can actually program (the point of Atwood's article) and setting up what would quite possibly be an uncomfortable situation for the candidate regardless of their programming prowess, thus making their results not match their actual skills. More to the point, people tend to freak out when they're being watched (if you've ever been in a meeting with people all collaboratively editing a Google doc you might have heard someone say "stop watching how I type!"). Even in pair programming situations, they tend to succeed when there's trust between the two people and the context is thoroughly understood.
There's also the question of what is it that you'd be evaluating in that live code session: whether or not someone can sit down and code without mistakes right out of the gate? How they start, edit, and iterate through code (the composition process, basically) to make it perfect? How much code -- good or bad -- they can produce in a given time?
Despite my own discomfort at being watched when I compose something , I can still see the benefit of a sit-down test like this if it is given to everyone at a certain stage in the process and you have given the applicant a heads-up including clear criteria for evaluation (e.g. what you're looking for: volume, "the right answer", how you work through a process, etc).
There's been a discussion recently in some circles of programmers/managers/hiring folks about giving candidates puzzles to work out during the interview, and whether or not that is/is not a good idea. I'm really against the puzzle idea (for all of the reasons David Heinemeier Hansson outlines), but what you're talking about is -- or can be -- different enough.