Live OS : secure file deletion
Running shred on a file in memory is pointless. The data from the file is also likely to be present in application memory, in caches, etc. Memory that belonged to a process it not wiped when the process dies: Linux, like most kernels, wipes memory before granting it to a process, not on release, because that's faster.
Of course, there's no guarantee that the file can be recovered. But there's no guarantee that it can't, either. If your attacker model is that the attacker can see your RAM content, there's a lot you need to take care of. At the very least you need to wipe RAM pages as soon as they're released by the process. You can apply the Grsecurity patches to the Linux kernel, at least the PAX_MEMORY_SANITIZE option. And you need to be careful about what processes are running and might store confidential information. And keep in mind that the kernel stores confidential information too, such as the RNG state and disk encryption keys. The TRESOR patch to the Linux kernel protects the disk encryption keys during normal operation, but it isn't a perfect defense and I don't know of a similar patch for the RNG state.
The danger you are trying to mitigate is filesystem journal, i.e. shred is not effective on filesystems that have a journal (e.g. ext3, ext4, reiserfs).
Assuming you are not using any unionfs for persistence (apparently you can do it in Tails although I never tried), everything is stored in a tmpfs.
The linux documentation on tmpfs does not detail whether is performs journaling. Yet, tmpfs is based on ramfs, the same filesystem that is used in initramfs, and that filesystem does not have a journal. Therefore it is (more-or-less) safe to assume that tmpfs does not have a journal as well.
On a filesystem without a journal shred will perform the overwrite of the file, making it difficult to recover with analytical tools (pretty much impossible to recover from a RAM dump). Since everything happens in memory pages, and the inodes of a tmpfs simply point to memory pages, using shred is much better because it will be able to write to these memory pages.
Caveat
The above certainly works in this way on Tails, and on Knoppix. It will likely work in a similar fashion on almost all Linux distros on LiveCDs, including Kali Linux yet there is a caveat.
This works for files! Memory will also contain application memory, see Gilles' answer on application memory. Seriously, look at that answer, it opens an important point.
Also a distro based on Ubuntu Linux (that may or may not include Kali Linux* since its predecessor, Backtrack, was based on Ubuntu) will mount any swap it finds on the machine it boots, which may leave a much worse attack vector! Persistent data on the device itself!
Another caveat with Kali Linux, is that it comes with metasploit and boots the postgres database for use with metasploit. Postgres has its own journalling (which is file based not filesystem based), which you may want to shred as well (i.e. shred the postgres files not just delete the data through psql).
* Kali is not based on Ubuntu, it is based on Debian, yet I am not confident whether it dropped all its configuration scripts from the time it was called Backtrack and was based on Ubuntu