So, my reasoning goes that if you're "tickling the SRAM directly" so it spits out bytes on cue then you're again having to make the memory system a slave to the very rigid timing requirements necessary for the video system. Which... on one hand doesn't seem like it should be a big deal, since that's how those 80's 8 bit computers were designed originally, but on the other it means that you're not really gaining much by using the Prop; you'll basically be using it as if it were something like a 6845.
The "caching" idea is that you can take a more relaxed approach: the Prop needs to grab one or two K inside of every 1/60th of a second window, but it could do it by, say, halting the CPU *once* and doing the transfer in one big chunk at the end of every vertical refresh cycle. IE, instead of having to master the intricate cadence of tossing the memory bus back and forth between CPU and video once every X cycles at precisely the right time you just halt everything for a thousand cycles once you're "offscreen", suck the contents of the RAM locations allocated to video at warp speed, or the closest it can achieve into the Prop, and then let everything go about its merry way again. That does have some implications for timing issues if you were explicitly trying to emulate an existing system, but I don't see it being a huge deal, and the "pauses" would at least be quite predictable.
Anyway, how well it would actually work in practice depends on just how quickly the Prop could suck bytes in from an SRAM. One thought I had would be you'd supplement the Prop with an 8 bit latch and a binary counter like a 74HC590; for a typical 16 bit address bus application before starting a transfer you'd load the high byte (let's call that the page address) into the latch (which sets the top 8 bits of the address bus) and reset the counter to zero. An actual transfer would consist of setting the 8 GPIO pins on the prop to inputs (or outputs, depending on whether you're writing or reading) and then just *tearing* through 256 memory locations at a time by triggering the increment line on the counter (which is wired to the bottom 8 bits of the address bus) for each transaction. Hardware-assisted block transfers like this are essentially how the optional SRAM card for the "Hydra" game system works, and the literature for that claims that you can read from that card into a COG as fast as a COG can access HUB memory. (Which means in theory you could clock the RAM *really fast* when the Prop controls it, while using a more leisurely clock for the master CPU. Another bonus of using the latch/counter system is you only need to use about a dozen GPIO lines out of the Prop's 32, instead of the essentially all of them you suck up trying to directly use them as address/data lines, and it's still less complicated than the alternative of using multiple latches and multiplexing. That leaves you with lots of I/O lines to use for other things.)
Again, that's totally just the *idea*.
Basically, yeah. All the truly classic 8 bit graphics chips (9918A, VIC-II, GTIA/Antic, etc) all have capabilities like that. ("Okay, move the space invaders left two pixels, let me know if the missile fired by the player hit any of the invaders, and if not go ahead and move it up a few pixels".). The cool thing about the Propeller, of course, is it's a fully general purpose CPU so in theory you could order it to do things like line/circle drawing, vectors, etc. (Also, you could wire a mouse to the Propeller and let the Prop completely handle the cursor generation, tracking, and even some of the high-level aspects of a GUI like window drawing and text handling. Think of it as a sort of Fisher-Price My First NeXT.)