The people saying you can't do it don't understand what you're trying to do.
A PIC cannot effectively act as as LCD controller that has to scan lines directly into the display. Nor does it have enough RAM to even hold a single screen buffer. But you aren't doing that. You've got a controller that will do the scanning and hold one or more buffers, you've only got to send read/write commands to alter pixels and the controller manages the buffer.
This is definitely MORE data transfer than a simple monochrome, monotoned (1 bit per pixel) graphics display. It's more resolution and more bits per pixel. But a display is not limited only by bandwidth, the computation to draw lines, graphics, etc takes longer than the transfer. So I can't predict how much slower it may be, it depends on what you need to do. Also the serial port that controller uses is probably a lot slower than a common 8-bit + rd/wr enable LCD bus. Maybe you can use the USART in the PIC to get a better speed by letting the hardware send out bytes while your code does computations to generate the bytes to send.
BTW, be aware that your PIC18F may have a 40MHz clock, but its instruction cycle is 1/4th of that, like all PICs. So if you were to make long string of PORTB=0xff; PORTB=0x00; PORTB=0xff;.... you'd only get a 5 MHz sq wave.