If you have a X server running and the DISPLAY environment variable is set to :0, that tells applications to connect to the X server using a unix domain socket which is generally to be found on Linux in /tmp/.X11-unix/X0 (though see below about the abstract namespace on recent Linux).
When you ssh to machine remotemachine, sshd on remotemachine sets DISPLAY to localhost:10 (for instance), which this time means that X connections are do be done over TCP to port 6010 of machine localhost. sshd on remotemachine listens for connections on there and forwards any incoming connection to the ssh client. The ssh client then tries to connect to /tmp/.X11-unix/X0 (on the local end, not the remote) to contact your X server.
Now, maybe you don't have a X server running (are you on Mac?) or maybe the unix domain socket is not to be found in /tmp/.X11-unix which would mean ssh hasn't been configured properly at compile time.
To figure out what the proper path is for the unix socket, you could try a strace -e connect xlogo (or the equivalent on your system) on your local machine to see what a normal X application does.
netstat -x | grep X may also give a clue.
For the record, on a Linux Debian wheezy machine here, Xorg listens on both /tmp/.X11-unix/X0 in the filesystem and /tmp/.X11-unix/X0 on the abstract namespace (generally written @/tmp/.X11-unix/X0). From strace, X11 applications seem to now use that abstract namespace by default, which explains why those still work if /tmp/.X11-unix is removed, while ssh doesn't use that abstract namespace.
You can test this without the rest of pymouse by firing up python and running
from Xlib.display import Display
display = Display()
display.record_create_context
which should print
<bound method Display.create_context of <Xlib.display.Display instance at ...>>
Looks like that corresponds to
$ xdpyinfo | grep -i record
RECORD
(that's under number of extensions: in the full output.)
If the latter doesn't show up, your X server doesn't support it, which is very unusual since it became part of the core server in July 2012 - which also explains why trying to load the module isn't working; there hasn't been a module to load since about four years ago.
python-xlib itself got record support in version 0.14 in 2007, so that's even less likely to be out of date...
Best Answer
Traditionnaly, Xorg was not able to detect and handle all the settings automatically and relied on external intervention to adjust them.
Xorg progressively developed and improved an auto-detection feature which allowed to generate a fairly good configuration file.
That feature eventually became so efficient that it was integrated with the normal engine initialization process.
When present, the configuration file takes precedence over auto-detected settings.