(Preface, this is RC.SE, not EE.SE, so less appropriate for such questions - so I wont go into schematic details)
a) Video RAM Access
As usual there are many ways. The most common are synchronizing CPU speed and video to
use 'the' other half. Or separate both RAMs and access only during pause. Or use a dedicated video chip already offering separation.
- Synchronized Memory
Eventually the most common in way used in 6502 systems - at least by number of sold units since every Apple II or Commodore does it. After all, a 1 MHz 6502 needs 2 MHz memory to function, but uses only every second 'slot' for access - leaving half the bandwith for some other device. In this case Video. To build it, a bunch of muxes are needed to access RAM from either (video, CPU) side. While it seams to offer simple access, it does have several disadvantages
Grabbing memory from already limited address space
Grabbing quite a lot for higher resolutions
CPU clock must be in sync with video clock, resulting in rather strange CPU-Speeds (*1)
For a new system I'd rather not go that way. It got way to harsh limitations.
- Separate Memory
This needs about the same set of muxes, but now not handled directly by the CPU, but via a few latches. While adding a tiny overhead in writing to RAM, it simplifies not only design and removes most of the obstacles from synchronized memory but as well
Speed of CPU can be set independent of Video and vice versa
Frees up lots of rare CPU address space as only 3-4 memory locations are needed within CPU address space, leaving all the 'rest' for program and data
Access latches can be organized independent of memory structure, offering a application centric view of like Rows and columns in separate registers
The last one will considerable simplify low level programming, more than offseting the added instructions to set registers, as now conversion between row/column and memory address is done in hardware.
- Use Of a Dedicated Chip
Add a 9928 or 9950, have it do all the video mode, RAM and whatsoever handling and concentrate on video output circuitry.
b) Character ROM access time
Well, it depends on all the timing you want to have. You got to do the math yourself, figuring out how it fits - after all, that's the most basic task here. If you're doing something like classic home computers, it'll be more than enough. Then again, doing it at 100 Hz and high resolution you may want to rethink the whole concept
Why a text mode at all?
Text modes are a classic way to save on RAM need for image storage. Quite handy back when each KiB counted, and large flat bitmaps were a high end luxury. But here you got high resolution bitmap, so why bothering with a text mode at all, complicating the design? Draw them, like next to any computer does nowadays. It'll be just 8 bytes instead of 1, done at quite low level, so not much slow down either. Especially when using separate memory (*2). Offering much freedom in character design and combination of graphics and text as well. There's a reason the very first Mac got bitmap (*3).
*1 - Think the odd speeds of various Commodores, making them run as well at different speeds depending on video standard, creating hurdles for timing dependant software. Or the variable clock length of an Apple II.
*2 - With readable latches a simple INC ROW will do all necessary address handling.
*3 - And as well why the planned 6809 got replaced by a 68k - having a considerable bitmap in 64 KiB address space sucks.