The problem with sending a WM_CHAR, or indeed any sort of message is that the cmd process doesn't have a message queue. The frame window does, but that's handling messages for the frame window, the system menu etc.
I have to say that, given the purpose is to get the output of a command into the text editor, I can't see a use case that requires it to be piped through a paginator in the cmd shell. There's no relationship between the dimensions of the cmd shell and the text editor, so it'll end up looking odd, and, presumaby, the user wants to do some editing of the output text in which case piping the output through a paginator is pointless.
There are a number of implementations of the MORE command, it's one of the GNU utilities, along with LESS, so getting access to source code isn't a problem. LESS is part of the coreutils available via ANPM, and is a far better pager.
An alternative approach would be to deal with piping the output from one command into another within the editor. Instead of passing a line of commands containing pipes to the shell parse the command line and pass each command seperately, collecting the output of each command and using that as the input for the next command in the pipeline. That lets you do your own paginationin the editor, where it makes more sense.