Well, you'll find the glorious smartphone screens are sold as replacement screens for smartphones.
But of course, smartphones tend to have an LCD controller on the SoC, so you just get a raw LCD parallel interface. That means the LCD has a tiny connector with dozens of wires. Hobbyists are often enough scared of soldering SMD parts, they won't try to solder that .4mm pitch connector.
Then you realise that even for 800x600 @ 60Hz you need a pixel clock of around 36 MHz, so you probably need a hardware controller, you can't really get away with DMA and/or bit banging. Since you have an external controller, you can't do any of the memory efficient drawing like Nintendo NES or sifteo[0], so you'll need external buffer memory, probably at least 2 MB to fit two (16 bit colour) frames for double buffering.
As the resolution grows, pixel clock frequency and memory size requirements grow quite quickly. Soon enough you get limited by the bandwidth between your MCU and controller, by limitations of parallel interfaces and have to switch to LVDS and so on.
Most of these issues become much less relevant if a (even small) company wants to design, manufacture and sell something like this. But I'm not sure there's a demand. For most projects a small screen (with a controller chip and available for cheap because it was designed and manufactured at scale for older phones) works well enough (and you can get away with using a wimpy 8 bit MCU). If you need a larger screen, it's probably cheaper to get a low cost single board computer and a computer monitor. Economies of scale and all that.
But of course, smartphones tend to have an LCD controller on the SoC, so you just get a raw LCD parallel interface. That means the LCD has a tiny connector with dozens of wires. Hobbyists are often enough scared of soldering SMD parts, they won't try to solder that .4mm pitch connector.
Then you realise that even for 800x600 @ 60Hz you need a pixel clock of around 36 MHz, so you probably need a hardware controller, you can't really get away with DMA and/or bit banging. Since you have an external controller, you can't do any of the memory efficient drawing like Nintendo NES or sifteo[0], so you'll need external buffer memory, probably at least 2 MB to fit two (16 bit colour) frames for double buffering.
As the resolution grows, pixel clock frequency and memory size requirements grow quite quickly. Soon enough you get limited by the bandwidth between your MCU and controller, by limitations of parallel interfaces and have to switch to LVDS and so on.
Most of these issues become much less relevant if a (even small) company wants to design, manufacture and sell something like this. But I'm not sure there's a demand. For most projects a small screen (with a controller chip and available for cheap because it was designed and manufactured at scale for older phones) works well enough (and you can get away with using a wimpy 8 bit MCU). If you need a larger screen, it's probably cheaper to get a low cost single board computer and a computer monitor. Economies of scale and all that.
[0] https://www.adafruit.com/blog/2012/12/05/how-we-built-a-supe...