After a number of ups and downs during assembly, I finally made a test print. It came out pretty well for a test print so I decided to try one of the 'torture-test' calibration designs on Thingiverse (see http://www.thingiverse.com/thing:1019228 for an example).
I ran that case through slic3r and it seemed to print the first 2-3 mm okay, then stopped reliably extruding or elevating the hot end and just seemed to smear plastic around until I killed the job. My assumption was either bad gcode or bad slic3r configuration so I installed Cura, configured it per http://reprapwilson.discoursehosting.net/t/silc3r-settings/37 and regenerated the gcode. I warmed up the printer, told it to print, and it put the bed-leveling limit switch down, rammed it into the table, and dragged it sideways. I killed the job, but not before the foot had been ripped off the limit switch. This was the spare limit switch since the foot broke off the first limit switch during assembly (this is a long story for another post).
I noticed this sort of problem during testing: the limit switches don't act like limit switches in that the machine will happily try to ram the bed, carriage, and extruder through anything in its path despite the limit switches registering HIT. I expect this was a design decision made by the original maintainers of Marlin, but can anyone explain why this behavior is allowed? I'm more familiar with industrial systems where limit switches are used to protect equipment from damage (e.g. valve actuators pushing the disk through the seat) so this design/behavior is really disturbing.
It's hard to see this as an oversight because there's space for 6 limit switches on the RAMPS board, switch position is clearly displayed, and the switches are actively used for auto-homing and bed leveling. I just can't understand why, if the machine has detected that a part has reached the limit of its travel, that information is ignored allowing the machine to wreck itself.
I'm happy to take a look at the firmware and attempt a fix for this problem, but I want to understand if this behavior is intentional, and if so, what the rationale for it is. I can't imagine a good reason for allowing this (preventing the robot apocalypse perhaps?) but I thought I'd ask.
Overall, I'm pretty happy with the machine; there are minor holes in the assembly documentation but overall my experience has been positive. The first test print came out far better than I expected. The second test print was junk (likely because of the stl to gcode conversion), the third one broke the machine. I need to reverse this trend, as soon as I get a new microswitch...
 Suffice to say the assembly video for the new rack-and-pinion bed leveling system should be in the YouTube playlist of Wilson II assembly videos. It would've saved me 2 days and a lot of frustration, especially soldering and resoldering the fragile leads on the limit switch.