While I think you're right jj in that the graphical and sound elements are really huge to making it a "game". I wasn't thinking of a traditional MUD where the story exists or it tried to hold your hand in anyway. I think a testing MUD would essentially be a text visualizer of the communication protocol between the client and the server. Allowing the client to type in any actions instead of interecting with a GUI or a world object as well as seeing the textual repsonse to from the server.

Ex: <Client>Request Move forward
<Server>Move forward acknowledged
<Server>Current Position = x,y,z

Since the server MUST be the master of the game, anything that affects the game will need to be transmitted back and forth between client and server. That data will most likely be human readable if not all that exciting story wise. Creating a Programmer's MUD allows testing of the comm layer and the client server protocol without needing to add the complexity of "the world".

However in a graphical game you might want a damage flyoff to take place after the enemy sword swing animation completes. This means you might need to break up how you calculate damage so that it is synched up with animation and sound. This is just one small example of dozens of little things that will be different.
This is a prime example, the animation sequence has nothing to do with the actual combat system or any other system. It's merely a client reaction to a server message.