First of all, 1 MS/s at 16 bit is just 2MB/s – that's really not too much for USB2 to carry. There's no need for dual port RAM, if we're talking about devices that would lend themselves to visualization or has PCIe like your Arch2 suggests, in my opinion.
The fact that you're doing visualization implies you don't care about latency – what's half a millisecond to the human eye? So, you're pretty free with respect to choice of sample transport.
Lots of components, including an FPGA that does nothing but write a lowly 1 million samples per second to a RAM interface. I'd say, if you go that way, use a feasibly fast bus, and that would include simple SPI or QSPI, and a bit of RAM with the FPGA to implement a ring buffer. No need for dual-port RAM – you'd need to communicate information like "ok, there's new samples available for you" or "no, nothing to fetch right now", anyways.
PCIe sounds like a huge overhead here. Again, the rate we're talking about is 2MB/s.
If your ADC, and your SoC allow you to do that, start with that! Certainly sounds like the easiest, lowest-component-count solution. Often, this doesn't work for electrical reasons. SPI is absolutely a normal interface for an embedded system to have, so I'd assume that it'd be rather easy to find a controller that has it.
Problem remains that you'd still need someone to e.g. generate your sample clock etc.
well, yeah, as you say, a less great version of 3.
1MS/s isn't really high-throughput. In fact, I remember writing firmware for a now defunct ARM cortex-M0 project that ran the internal ADC at 500kS/s and pushed the data through USB2 to a PC. With a slightly more capable MCU, you should be able to do the same. That way, you'd have cheap-as-hell device dedicated to handling ADC data and stuffing it in USB packets, and you'd just have to write a couple lines of Python or C to run on your embedded device to ask the microcontroller for USB bulk packets full of data. Bonus: you can clock down your main CPU whenever you want to, and it will have no effect on the sampling.
Kinda easy. You can all do minimal visualization, sampling at several megasamples per second (complex) and a bit of analysis on ARM cortex-M4, with the help of a bit of glue-FPGA (without own RAM, iirc). This is proven by the open design of the HackRF one. I think it might be worth for you to look into this. From my perspective, it sounds like you'd basically just want to throw out all the RF stuff in that, and use it as is. You'd even get drivers and firmware for free!
HackRF hardware components diagrams from the project wiki
Above diagram is simplified, as mentioned, there's a small "glue" FPGA between the ADC/DAC hybrid and the LPC Cortex-M4, as the schematic will tell you.