No, it’s not possible to use a different driver as we’re talking about completely different protocols here. The card itself speaks what’s essentially the SD/MMC protocol. A USB mass storage device however talks in what is essentially a SCSI protocol. So an adapter translates the SCSI commands it receives from the host computer to SD/MMC commands and back. However it does not translate each and every one as some commands have no corresponding one in the other. E.g. you can’t translate a SCSI UNMAP command (its a TRIM equivalent) as SD cards don’t support something equivalent ((e)MMC’s would however) while you can’t represent the card’s write protection flags in SCSI commands. That’s why the Cypress Astoria I mentioned provides a passthrough of SD/MMC commands through the SCSI protocol (something akin to ATA passthrough that some USB-SATA adapters support).
At least from a technological point of view it should be possible to use password lock and the write protection bits in smartphones as they usually have a SDHCI or communicate directly with the card on a SPI bus anyway (e.g. many embedded ARM boards do it this way; you could even bitbang the protocol with a few GPIOs).
A quick Google search turned up a few tools that might be of use, though you’d probably need to include corresponding user interfaces for Android yourself:
sdtool (to set TMP and PERM write protect flag)
mmc-utils (uses a different way of communicating with the driver; for an example see here)
sdlock (Tool to lock/unlock the card with a password)
Note: I’ve just found these and tested neither of them, so handle with care, especially considering the permanent write protect flag as that is exactly what is says on the tin!
Speaking of which: the physical write protect switch is something completely different than the two flags I’m talking about. The switch merely triggers one of the card’s pins (the Write Protect pin) and can be completely ignored by whatever hardware the card is directly talking to (e.g. there can be USB mass storage adapters, especially cheap ones that don’t give a damn about the switch while others might respect it). The two write protect bits TMP_WRITE_PROTECT and PERM_WRITE_PROTECT however are enforced by the card’s firmware and thus can’t be circumvented. As mentioned above especially the latter permanently write protects the card (useful if one distributes software that shouldn’t be manipulated anymore).