Not impossible, but here are the obstacles to overcome:
First, the SD card knows nothing about FAT, ext4fs, or any other file system. What it does is accept commands from the host interface and either store the data given to it, or retrieve data and send them back to the host. The filesystem interface is implemented at a higher layer. Whatever you create will not (should not, cannot) know anything about filesystems. You need to create something that serves blocks.
Second, there are two modes to communicate with the SD card: SPI mode and SDIO mode (there is actually a somewhat-newer physical interface involving an additional row of pins, but I think this extends the SDIO mode, it does not involve a third mode. I could be wrong. SDIO mode is a lot more complex to implement; if you look at the Arduino (and other such systems) libraries for how they access SD cards, they use the simpler, but a lot slower, SPI mode.
Your question now can be rephrased as: "Is it possible to implement either the SDIO or the SPI sdcard interface on the Pi?". If this is true, you can then have a chunk of storage (on a USB-connected drive, or even on the on the on-board sdcard) that you are exporting over the sdcard interface as if it were the flash chip that sdcards use. (In fact, sd cards have their own tiny embedded OS that does exactly that -- Bunnie Huang from MIT has written about it, and how to hack it). What you put on that chunk is up to you; you can rely on the other side to store/retrieve data, or you can put a filesystem on it, mount it, store stuff from the Pi side, unmount it, and then let the other side play with it. Obviously, you should have the chunk mounted as a filesystem both from the Pi and the outside at the same time (OK, obvious to me; the reason is that some metadata is not written synchronously, and what's on the chunk of storage that you are exporting may not be a consistent filesystem).
Already it's a tremendous amount of work to implement this; you'd have to implement the SD card specification (start at www.sdcard.org; they have the simplified specs available, but you need to be a member to get the full spec).
Add to all this the complication that, while sd cards have to support the SPI interface, the host controller may not be implementing it, so you could end up implementing all this complexity to export an SPI-interface-only card, which cannot then be read from the particular machine you may have. There aren't too many sdcard controller chips out there, and you may be able to figure this out by reading the corresponding linux device drivers.
You are still not done. Even assuming the simplest (but still not simple) case, where you will be implementing the SPI interface, you are stuck with the fact that the Pi does not support SPI slave mode. So you'd be back to having to bit-bang the SPI (or, worse, the SDIO) protocol on the GPIO pins, which would have to be done inside the kernel with interrupts disabled so as not to mess with the timing. Even if you are implementing a very slow sd card (which you could tell the host when it asks what kind of card you are), that would be about a megabyte per second, or eight megabits, and when you are running at 800MHz, you'll have about 100 clock cycles for each bit in which to read the status of signalling pins, decide what to send out, and send it. Not impossible, esp. if you can take an interrupt at the rising edge of the clock pin and can have some stuff precomputed, but that's a rather tight timing budget, and you'd have to do a fair amount of assembly coding.
You are still reading?! :)
Now for the good news: you may still fail, but you'll have learned more than most people about sd cards, spi/sdio, file systems, interrupt/real-time programming, and kernel device drivers :)
