Your right about 1), and that leads into 2)

we know the actual length of the top side, as it dotDistanceInMM.
From the first line we know the angle (each pixel on the camera in the wiimote represents a set amount of angle).
This is a isoceles triangle, so dividing both by 2 gives us a right angle triangle, the white area in the picture. Pythagorean rules for right angle triangles define
Tan(angle) = opposite / adjacent
or in our variable terms
Tan(angle) = (dotDistanceInMM/2) / headDist
adjacent is what we want to find (headDist), so rearranging:
headDist = (dotDistanceInMM/2) / Tan(angle)
the other 2 terms (confusingly 1 at the start and 1 at the end) are just scaling factors, the first allows use to exaggerate all movement if we want to, and the second normalises by the size of the screen. Not totally sure about this bit, it means if you have a large screen everything seems bigger, bit if you have your head in the same place you see the same thing (as opposed to be being able to see more)
3) combines a few operations into 1 line of code. So working outwards from the middle:
avgX is the midpoint of the head from the far left of the camera
avg-512 is the midpoint of the head, with 0 being right in the centre of the screen. -ve 1 side and +ve the other.
radiansPerPixel * (avgX - 512) = the angle of the centre of the head from the centerline of the camera, so again -ve angle is on 1 side and +ve on the other.
Now we construct a very similar triangle to last time:

where we know headDist, and angle, and want to headX.
Sin(angle) = opposite / hypotenuse
Sin(radiansPerPixel * (avgX - 512)) = headX / headDist
rearranging:
headX = Sin(radiansPerPixel * (avgX - 512)) * headDist
again add in the movementScaling term to allow exaggeration.
headY requires a bit more, as we dont assume the camera is horizontal (but we did assume it was perpedicular to the screen for headX).Also it needs to take into account being above or below the screen (again for X we assumed the wiimote was in the middle of the screen).
so we add on cameraVerticaleAngle (nicely misspelt).
and then add or subtract 0.5 depending on where the camera is.
Why 0.5? because ever since we "/screenHeightinMM" in 2) we have been work in terms of screen heights. so headX would say "head is 1 screen height left" and headY would say "head is 0.7 screen heights up". So if the camera is half a screen height above the TV we need to subtract 0.5 to move to the middle of the TV.
so From this we have an X,Y,Z (headX,headY,headDist) co-ordinate of the head relative to the dead centre of the TV screen.