Turns out, the reason behind the SD card refusing to init was painfully stupid. My theory was that the SPI clock was too fast for the special transaction that takes place to bring the SD card from native (SD) mode to legacy (SPI) mode. So, I added more VHDL to include a second clock source for a slower SPI rate (375 kbps) and a bit to select between it and the faster rate (3 Mbps). Modded the sdtest.asm code, and...nothing. A few minutes with my trusty Saleae logic analyzer (I cannot say enough good things about this tool!) confirmed that the SPI rate was switching correctly. But it also let me see that the bits were shifting out of the SPI master in reverse order; that is, LSB first, MSB last. Ugh. That'll teach me to not double-check borrowed code. So, I fixed it. Voila! Working SD transactions! It even works without slowing down the SPI rate for the init sequence. But, I'll leave the two-clock-rate capability intact, because a slower clock is mentioned in most SD/MMC writeups. I did cheat a bit and economize, however: the 'fast' SPI rate is now 6Mbps and the 'slow' SPI rate is now about 460kbps (used the SCC baud rate reference clock for the slow clock). 

There's one lingering issue with the fact that I cannot run my sdtest.asm prog twice in a row without removing and replacing the SD card in between runs. I don't think this is a hardware issue, however, and more of a software topic.