It might be possible, but
Such displays often use a parallel interface (4, 8 or more data lines, lots of control lines) and the Pi has only a few GPIO available on the extension connector. (You can guess the number of GPIO simply by counting the wires in your interface - likely a flex cable).
I don't think anyone has done this yet, it will not be easy, and there is not much incentive to do this for any particular screen.
So unless you are in it for the thrill (and willing to spend a lot of time on it) I would say: forget it.
A suggested approach to updating a 1200 x 800 pixel display at 1000 fps, would be to break up the display into a matrix of lower resolution OLED panels, ideally OLEDs with so-called "edge-to-edge active display". For instance, a 2 x 2 matrix of 640 x 480 OLED panels would provide a bit more than the specified resolution. However, these sub- panels selected must themselves allow refresh rates of 1000 frames per second, as well.
Each panel needs to be controlled through a separate signal channel. Depending on the capability versus price of the FPGA chosen, a single FPGA may be used to drive one or more of the panels.
This is similar to the way ultra-large displays are created for stage performance backdrops, for instance, using a matrix of standard large screen HD LCD or LED televisions. Each TV is typically driven off a separate video source. Allowance is made for bezel distances, cropping off an appropriate amount of the image at each edge of each TV.
As the application itself is not described in the question, an assumption is that a somewhat contiguous display is required. Unfortunately, using separate panels will not provide contiguous display area, as the connections to each OLED panel in the matrix have to come out somewhere. Thus, bezel-like gaps will need to exist between panels, similar to the matrix-of-TVs approach mentioned.
If this is unacceptable, the alternative is to select an OLED panel of the desired resolution, that brings out individual signal rows and columns to a connector and allows these to be driven in definable banks. Typical OLED panels with Chip-on-Glass (COG) controllers will not work this way, raw OLED panels will need to be sourced.
Individual banks of OLED rows / columns would then be controlled via separate channels and conceivably separate controllers, to achieve the desired end-result display.
Best Answer
Not only do the two TV systems run at a different frequency, but the difference in frequency also dictates a difference in frame size. PAL is 625 lines, whereas NTSC is 525 lines. That means that games (and the consoles) have to account for that difference in size in their graphics and playfields.
And then, on top of that, the two systems both use a different colour coding scheme1. The hardware in the console has to be able to do the right colour encoding to be able to display on the right kind of screen. You can't just plug a PAL console into an NTSC screen and expect it to have a clue what is going on - the same the other way around.
Most games consoles tied the action to the video output frequency. Frames were calculated and drawn at the same frequency as the screen, so the gameplay was often quicker on an NTCS console than on a PAL console. The internals of the console had to account for that change in speed, and so they would usually have a different core clock (and different crystal value) for NTCS devices as compared to PAL devices.
So you see, the TV standard the console is designed to work with affects a lot more than just the frequency of the TV signal.
1 NTSC used to be known as "Never The Same Colour" as the colour coding system used in it was quite poor by comparison to PAL. You could never quite trust how the colours would be represented from one device or broadcast to the next.