(Edited, as the focus of the questions has changed quite a bit).
First, let me make clear that getting a "perfect V-sync image" is necessary, but far from sufficient for "visuals identical to original arcades and retro computers". CRT TVs have a lot of artifacts due to the analog nature of the signal. Having proper v-sync will avoid tearing, which is a very obvious flaw when emulating, but that's all that it does. It won't give you an experience that's close to the original visuals.
Now, to the various parts.
Using emulation systems with TV out
Video cards with composite TV outputs exist, from quite a few manufacturers. The bulk of that would be AGP cards, with a few PCI cards thrown in. I think finding a PCIe card would be a challenge.
So (1) is difficult, (2) definitely doable (if you have the right motherboard).
Those cards used specific encoder chips (mostly Philips, Brooktree/Conexant, Chrontel) with varying capabilities; timing was often constrained (the Chrontel chips only support few modes). Later NVidia cards used their own proprietary TV encoder. Programming those chips is done via I2C bus, if you want a specific resolution, you'll need a datasheet (I still should have them somewhere).
An alternative way that would need a considerable amount of hacking is to use a Fresco FL2000 VGA dongle. This have been repurposed as general D/A converters, and the bandwidth should be enough for a composite TV signal, at least black and white (maybe also with color). With some use of the other two channels maybe one could even use something closer to the original VGA mode, and somehow put a SYNC signal in.
That would be a fun project, but requires some good programming skills.
As for (3): I wouldn't think an actual retro computer with TV composite output only has enough processing power to successfully emulate another retro computer of the same era at a reasonable speed.
Perfect V-Sync
Perfect V-sync is easy, and is a problem of the emulator software communicating with the graphics card, and the graphics card producing an image with the correct (multiple of the PAL/NTSC) vertical sync frequency. For that, it doesn't matter if you use a CRT TV or an LCD monitor.
You could ask for an interrupt every frame and thus do things exactly once per frame. As long as you updated visuals after they were drawn (not during), you got a perfect picture. How does this work on modern hardware, eg. a Rpi?
In the same way, it's just that the graphics driver, kernel, OpenGL etc. put a lot more distance in between the hardware interrupts and the application problem.
Does the CPU have access to something identical to a "raster register" or "timer" that lets it spit out exactly one picture per 1/50 second (1/60 for NTSC)?
Yes, it has. However, the raster line counter and/or retrace interrupts are only accessible at the kernel/driver level. They get passed on to the application program via various APIs, depending on the OS, graphics library etc.
Is there any one or two way communication between CPU and video card?
That depends on what you mean by "video card": The part responsible for the timing and framebuffer readout can be programmed by writing values to registers, and gives feedback by reading registers or interrupts. The various GPU ("graphics CPU") are a different topic.
Or is the CPU completely oblivious to the video card / connected monitor, and just does a "best effort" at trying to produce sequential images, which means that visuals will skip a frame sooner or later?
The "CPU" isn't, but an application program like an emulator may be, in particular if it's not reprogramming the graphics mode, but using whatever mode is currently selected (which many emulators do, because it's more convenient).