^Basically, yes, I'm saying that I would account only for the translations of the ball on the vertical plane. Mapping this plane to the "aiming" plane is all in the calibration, as the active area could be a 50x30 cm2 rectangle near your lap and the center in a comfortable position.
As for accuracy, i would need to know some more technical details, such as the camera's field of view, to calculate a few rough numbers, but from the user's point of view it would be the same kind of movements of a wiimote pointing based games so the troubles with steady hands would be about the same.
Btw, accelerometers are not slow at all: the Wiimote ones sample at 100Hz, and that's a 5 year old spec. The trouble is that they have scarce resolution, and of course without gyroscopes they are no good at tracking rotations on the horizontal plane. Add gyros though, and you have a lot of fast data.
I think that the compass thing is used to auto-calibrate the gyroscopes on the horizontal plane since it "knows" which angle you started from -relative to the north-south magnetic line- reducing the need to do so explicitly by having to point at the screen.
All speculations, of course. We'll know in due time.
Update: according to the info given at the following dev conference, that's not how they code pointing. They're actually using all the data, including rotations, and projecting the direction to the tv screen plane. Anyway, they say that the standard library that all devs get to use can track all the data from 4 wands in under a frame time (I suppose they mean 1/30th of second) on an SPU. Interesting info in the Eurogamer / Digital foundry report. We'll have to see if the final software can match the theory.
