I looked back over some of the documentation just now - if I'm not mistaken, Copper MOVEs take 560ns (four cycles) to execute. Running with my true-color idea, that would make a bitmap of 80x(screen height) theoretically possible, though I don't know how stable it'd be in practice.
You're pretty much right, as far as I remember. The caveat is that anything else that can steal DMA cycles will cause the copper to miss one or more colour changes, and the blitter and CPU will pretty much stall on any accesses to chip RAM while you're doing this. This is from the hardware guide:
Disk DMA, audio DMA, display DMA, and sprite DMA all have the highest
priority level. Display DMA has priority over sprite DMA under certain
circumstances. Each of these four devices is allocated a group of time
slots during each horizontal scan of the video beam. If a device does not
request one of its allocated time slots, the slot is open for other uses.
These devices are given first priority because missed DMA cycles can cause
lost data, noise in the sound output, or on-screen interruptions.
The Copper has the next priority because it has to perform its operations
at the same time during each display frame to remain synchronized with the
display beam sweeping across the screen.
The lowest priorities are assigned to the blitter and the 68000, in that
order. The blitter is given the higher priority because it performs data
copying, modifying, and line drawing operations operations much faster
than the 68000.
In other words, any disk, audio, display or sprite DMA can or will interfere.
