Thanks, ellet, for the suggestions.
Geek warning: the following will probably be of interest only to those of certain kinds of disposition.
I don't run an X server on my arm box (currently a Dreamplug) - too wasteful of resources. Instead, it has the minimum necessary to allow connection from a machine (with a display and kbd) running an X server, using ssh -X, with X forwarding - so e.g. the calibre gui will appear on the connecting machine's display. Contrary to what I said in one post above, this does current work well (but there's sometimes a weird effect apparently when trying to set up a second X fwding after closing down a first, within a single ssh session - getting the response "cannot connect to the display localhost:10.0" - I don't at present understand this, but renewing the ssh connection solves it).
In this context, I can't really "disconnect the X window session" as you suggest, since the calibre process is a child of the ssh terminal session - and e.g. shutting down the connecting machine kills that, of course.
However, as they say, we have tools for this kind of situation. Enter GNU screen. Within an ssh connection to the dreamplug, I start a screen session; fire up calibre (gui) within it; detach (^a^d) from the screen session - and the gui keeps running; start up the wireless device connection from the gui, and e.g. connect to it from an android device. Now I terminate the ssh connection. Most programs will continue running within the detached screen session. Unfortunately, the calibre gui terminates itself when the ssh connection disconnects - presumably, and not unreasonably, because it finds itself unable to write to the X server.
So, at the moment, I'm out of ideas about how to pursue your suggestions, unless I install a dummy X server on the dreamplug - but then I've no idea, without a command line command or option, how to kick it to initiate the wireless device connection - except perhaps via your "autostart" suggestion, which might work. But I'm a bit reluctant (maybe unreasonably) to load the dreamplug with continuous running of a really unnecessary set of X server processes. You should see how slowly the calibre GUI runs on it with X fwding! (Usable, but only just - the price of very low power consumption.) In contrast, the content server runs perfectly acceptably.
Thanks again for your suggestions - but chaley's point that, at present, the device connection system is a subsystem of the GUI, really pretty much kills a rational client-server type approach to this (it seems to me).