For an exercise people, when your screen locks, with mouse cursor still moving, but the X server consuming 100% of the cpu, log into the computer over the network and run an strace on the X server process.
When I do this on mine, the only activity is the continual receipt of a signal - which may explain the 100% cpu usage. It looks like a condition is occuring which causes a signal, but the handler returns without doing something to prevent re-occurence of that signal, so it simply jumps straight back into the signal handler again.
Don't know enough about how the X server works to understand why the cursor still moves - although I vaguely remember seeing different activity in the strace when I moved the mouse - probably other events are still being handled in the signal handler - just not the one that would prevent the hang.
It might be interesting to connect gdb to the X server process too, because strace doesn't give enough information to tell whats going on - but that requires time, and usually a debuggable X server, though even using the standard X server binary might give a clue as to which signal is killing the server.
Or it may be that this is normal signal activity for the X server - it may just look like a lot because it is streaming to the screen. I suppose a signal every few hundred milliseconds wouldn't be too bad considering what the X server does. Getting strace to report the time diff between system calls should answer this question (but I didn't think of that at the time).
Anyway, more information like this couldn't hurt, could it? Cheers!