You didn't mention which PIC you are using, but assuming it is one of the smaller ones such as the PIC16 then with it's limited RAM (99% of PIC16's have no more than 1K of RAM) it would be impossible to implement even a FAT16 file system since multiple 512 byte buffers are needed. (Microchip has a useful library to implement a FAT16/FAT32 file system but it is only applicable to the PIC18, PIC24, dsPIC33 and PIC32.)
You did mention that due to limited RAM, you would like to just write or read a byte at a time. Although, as others have stated, an SD card is typically broken up into 512 byte blocks, you don't need to use all of the bytes. Worse case, you could store just one byte per block and waste the other 511. This seems preposterous, but due to the enormous size of the SD cards available today it would actually work. If you have an 8GB card, than means there are 16M blocks, which means you can store 16 MB of data in this way.
However, it is going to be very slow, something like 10 ms or more per byte, because you are going to have to issue a command to erase each block before it is written. You didn't mention the amount of data that is contained in one of your log entries, but it would be much much better if you could buffer up one entry (say 25 bytes or whatever that is) and write that to a block. So each block becomes a log entry. Because the time to write the bytes is once again dominated by the time it takes to erase the block, writing out an entry log entry will be as fast as writing a single byte.
Since you are essentially using this as extended memory, you don't have remove the card and read it in a PC (which would require using special software to dump out the raw blocks). Instead, since you already have the read block routine in your code anyway, and assuming you have a UART, I would dump the log data out in a serial fashion to a PC; you could use a FTDI UART-to-USB bridge and the data would appear on your PC as a COM port.