Unfortunately the camera has a NTSC output and the LCD has a SPI input, is there any way I can get the footage from the camera to display on the LCD or will I have to use a different screen?
Well you would need to digitize the video, extract luminance, chrominance & sync information, downscale from 525 lines to 128 lines and output the data over SPI in real time. This sounds like a non-starter to me.
It would be easier to use the JPEG digital output from the camera and decompress this, since the resolution is compatible with the screen (160 X 120 vs. 160 X 128) although you still wouldn't get real-time video.
EDIT: I was wrong about the video through the TTL interface: you can take snapshot and send them through the UART, but for the video the only way is the analog output. So for it you will need a fast ADC and digital manipulation, and it won't be so easy.
Though, you can use it to send pictures with a low framerate, like "real-time" weather monitoring webcams.
What you need to define is the encoding of the image from the webcam (bit depth and framerate) and eventually write the code to convert it in a format compatible with the display (it has different options, read the datasheet).
It may be possible also to forward directly the image from the TTL input to the SPI input without processing, but you still have to handle the communication and it will be easier if your uC has both the UART and SPI interfaces.
So it's not impossible, but requires some work.
Capturing a black and white NTSC video signal isn't overly difficult, especially if you're not too worried about resolution or frame rate. There was a video capture gizmo that plugged into the printer port of an Amiga 1000, for example. No fancy zillion-megahertz microcontrollers back then--just some discrete logic, a sample-and-hold, and a not-terribly-fast ADC which IIRC captured 5-bit data at 15KHz (about 5-seconds per frame, black and white). I would expect that you would want to, and could, capture monochrome data faster than that with a decent microcontroller. If you want to capture a crude 128x100 image at 30fps, you'd probably need to capture about 0.8 megapixels/second (capture 1/4 of the pixels horizontally on each scan line, on two fields).
Capturing color from a "general" NTSC video source is much harder, since there's no fixed relationship between chroma phase and horizontal position. Many video sources, however, including cameras, computers, and DVD players do have a fixed relationship between chroma and horizontal position (there is a standard for what the relationship should be for "perfect" video, but not all devices comply; most devices other than VCRs will have a consistent relationship, but they may or may not match the standard). If you can design around a particular known input source, and can accurately measure timings with regard to horizontal sync (timing precision will be much more important than with monochrome video) color sampling may be practical.
Without knowing what you're wanting to do, I can't say what the best approach would be. You might be best off using an LCD display with a composite video input and overlaying video on that. Color overlay is generally a pain, though if you want a horizontal "split screen" it might be possible to cheat (sets with analog color circuitry would not work well if one part of the screen used different color phase from another part, but LCD screens with a digital front end might not mind; if you generated your own chroma on lines where you wanted to display your own color, and let the camera chroma through on others, I'm not sure what would happen).