I sort of understand how graphical terminals work: you have a master process running something like xterm and a slave process running a shell. The master receives keystrokes, displays them in the window and passes them to the slave, which thinks they come from a terminal called /dev/pts/pty(n). The slave sends its output to /dev/pts/pty(n) but it actually goes to the master which displays it underneath the input.

But why does this need a serial console? I know it must because, if you tell the evdev input driver to ignore the /dev/ttyS devices reported by udev, the xterms don't work.

Not really.
There is an OS, which will detect keystrokes, mouse events and similar. It will send it to an app (or probably better to say there is an app which will take the events from the kernel). This is Xorg and it will find out which app is currently in focus and will forward the event to it (this is xterm actually). Xterm itself will do more or less the same, either it can handle the event itself or will forward it to the app which is running "inside". But xterm has no idea what is really running inside, it just will create a "pseudo" tty (=/dev/pts/....) and will pass it to the command specified (this is usually bash) (passed as file descriptors 0, 1, 2). bash has no any idea about GUI, it will read the tty it has. bash also sends its stdout "back" to this pseudo tty and xterm will take care about it (=display chars for example).
I would not say master and slave at all.
I don't think xterm itself really needs serial console, but in special cases... Would be nice to explain exactly what did you try. What do you mean by xterm does not work?

All the articles I have read about pseudo-terminals use the terms "master" and "slave". They seem to be standard terminology. Of course you are right that xterm doesn't receive keystrokes directly but from the xorg server.

All this arises out of a beef I had with xorg in Crux. When I looked at Xorg.0.log, there were loads of unsuccessful attempts by xorg (or more likely by the evdev driver) to turn the tty devices discovered by udev into input devices for X. This doesn't happen in Debian or LFS and I wondered what was causing it. Someone suggested adding an xorg configuration file telling xorg to ignore /dev/tty and /dev/ttyS devices. When I did, I found that I couldn't launch xterms any more. If I told X to ignore /dev/tty devices only, the xterms work. And I just would like to know why this is.

Unfortunately I can't tell you what "doesn't work" means here. Usually if a program won't launch from a menu or icon, I launch it from a terminal instead, and the error messages tell me exactly where things have gone wrong. But you can't launch a terminal from a terminal if you can't launch a terminal!! So I don't know what is going wrong, only that no xterm appears.

what I can imagine xterm could not create that pseudo terminal and therefore unable to work. You can go to console and try to run xterm from there too. Or construct a desktop icon to start a shell script which will try to start and save stdout/stderr (and probably strace) of xterm.

How do I do it from a console? Do I have to specify the display or something?

yes, specify DISPLAY or use xterm -display
but probably you will need to switch off access control first (see xhost)

This is weird! I restored the configuration file, telling xorg to ignore both /dev/tty* and /dev/stty* as before. Then I stopped and restarted X. I went to a console, typed DISPLAY=:0 xterm, and lo and behold, a terminal appeared on my desktop! I closed it, clicked on the terminal button on my buttonbar (which is how I usually launch things) and another terminal appeared. I don't know why it didn't work before and I suppose I shall never find out. I'm going to mark this as solved because I now know the answer to my question: an xterm does not need a serial console.