koikoi is right, using the LCD for a hobby project looks like it will be a minor mess, due mostly to the LCD's timing requirements. For example, you can run most PICs with an external oscillator of up to 40MHz (just watch for "but it screws up above 4MHz" in the errata sheets), which because of the 4-clock instruction cycle gives an instruction clock of 10MHz. So this means that even if your PIC code did nothing else except flip a clock line up and down, the maximum rate you could clock at (set line high, then set line low) is 5MHz, still not fast enough to drive the LCD.
But now you've got me thinking....
What probably needs to be done, is to implement a basic "clock data into the LCD from a memory at 5.67MHz" circuit on an FPGA. I guess you could even do this with a bunch of 74LS... chips but this could get messy. Then use your PIC to control the image that's actually in the memory. You of course won't be able to display anything at a video-like frame rate, but this should be fine for static images.
"But how do I update a memory while the FPGA is reading from it?"
There you're on your own. What I would do personally is implement a 'disable' pin on the FPGA, which would float the pins tied to the memory. Then you can rewrite the video display at your leisure with the PIC (nothing is being displayed on the screen at this time), then re-enable the memory access to the FPGA. If you want to get fancy and avoid blacking out the screen while changing the image, there is such a thing as 'dual-port' (or multi-port) memory, which can be read and written at the same time via separate address/data lines. Haven't checked how expensive this stuff is, though. You could also time it so that your PIC races in and changes the video memory during the "blank interval" (the little bit of downtime between writing the last pixel of the current frame, and the first pixel of the next frame), but that doesn't give you very much time at all.
You'll need up to 64KBytes of memory for the 280x220 image, depending on how you store it in memory. Remember that the "pixels" on the LCD are actually individual, staggered RED / GREEN / BLUE dots, not the standard square matrix of any-color pixels you're probably accustomed to. So, your PIC (or PC program talking to it, etc.) will have to do some translation to convert bitmap images, text, etc. to a format that will display correctly on the LCD. The 280x220 refers to these *dots* as far as I can tell from the datasheet; so the 64KByte figure is accurate if you store the data in the logical "1 byte -> 1 dot" way. The LCD only uses 6 bits per dot though; so you have an extra 2 bits per dot where you can store whatever you want (or nothing at all).
What I would probably do (considering I had a nice big FPGA to play with) is use the 6 bits to store an actual "true-color" background image, and use the remaining 2 bits to specify one of four programmable "overlay modes" for that pixel. The FPGA would have to do the overlaying in real-time, but this would allow you to set e.g. an overlay color and mode for each of the 4 possible slack-bit settings.
E.g.: Mode 0: Transparent (do nothing); Mode 1: Set this pixel to user-defined color [Bright Red] (ignore 6-bit color information); Mode 2: Add user-defined brightness (0x26) to 6-bit value before writing it to the LCD...
This way you could display e.g. text (quote of the day, weather reports, time/temperature) over a background image, without altering the original image and without requiring another 64KBytes of expensive memory as a frame buffer to store the original (for when you want to erase/change the text). Changing the entire text from, say, opaque fuschia to smoked-glass transparent would be as simple as writing 1 or 2 bytes to the FPGA (or a couple of the slack bytes at the end of the RAM, which the FPGA will read during the blank interval).
