If you've already got all the appropriate code to separate out the GUI into a separate thread and communicate with the networking components via message queues, then this should work just fine.  Normally I'd suspect wx (which I find to be a highly idiosyncratic, buggy, and arbitrarily limited library: have you considered using something else for your GUI?) might have some difficulties that I'm not aware of, but I'm pretty sure several other Twisted users have already done this exact type of integration.

Personally, regardless of UI toolkit, in this situation I'd have the server start up with a "normal" reactor (select, poll, epoll, kqueue: take your pick) and have it spawn a separate GUI process with the GUI reactor, and communicate via a socket.  That way the GUI can be shut down and restarted without killing the back-end, and the back-end could be moved to a different machine.  But I don't know a lot about your application and there may be some requirements I'm not aware of :).