Try downloading install-tl-unx.tar.gz . Create a folder called texlive2013 inside your home directory and install TeX Live there. You could also install it on a portable
hard drive or a large capacity memory stick, but in the latter case compiling may be painfully slow.
This worked on a linux machine on which I do not have admin privileges (it was necessary because it had a prehistoric TeX installation). I think it will work on a Mac as well. You will probably need to manually edit your login script so that the path environment variable makes latex, pdflatex etc. available from the terminal.
For an editor, try running emacs from the terminal; it may be installed already. If it doesn't work, you could try emacs -nw (which runs emacs in the terminal window itself). Failing that, there is always vi, or just edit your LaTeX files using TextEdit, or another text editor that is already installed.
EDIT
On second thoughts, you can probably install an editor of your choice in your home directory or on a portable storage device. Most OS X applications don't care where they are installed.
Suppose you have three installations of TeX on your machine, say vanilla TeX Live 2014 and 2015, along with the TeX Live provided by Ubuntu/Debian. The binaries for the three distributions will live in
/usr/local/texlive/2014/bin/<arch>
/usr/local/texlive/2015/bin/<arch>
/usr/bin
where <arch> might be i386-linux, x86_64-linux or another string relative to your machine's hardware architecture.
If you set your PATH variable with
export PATH=/usr/local/texlive/2015/bin/i386-linux:$PATH
in your .profile file or with the method of adding a file in /etc/profile.d (which I recommend), then calling
pdftex --version
from a shell will show
pdfTeX 3.14159265-2.6-1.40.16 (TeX Live 2015)
kpathsea version 6.2.1
[...]
and you're sure that any TeX program will use the tree located in
/usr/local/texlive/2015
This is because of how the kpathsea library, which all TeX Live programs are linked to, works: it sets a number of runtime environment variables based on the directory where the called binary lives in.
You can try seeing this by doing the following distinct calls from the shell (again, use the string for <arch> corresponding to your machine's architecture)
kpsewhich plain.tex
/usr/local/texlive/2014/bin/x86_64-linux/kpsewhich plain.tex
/usr/bin/kpsewhich plain.tex
and you'll receive three different answers:
/usr/local/texlive/2015/texmf-dist/tex/plain/base/plain.tex
/usr/local/texlive/2014/texmf-dist/tex/plain/base/plain.tex
/usr/share/texlive/texmf-dist/tex/plain/base/plain.tex
The program kpsewhich is the public interface to the kpathsea library.
You may get into big problems if your PATH is not set in such a way that the GUI applications see the vanilla TeX Live binary directory before /usr/bin. In my test virtual machines I place a file called texlive.sh in /etc/profile.d containing
export PATH=/opt/texbin:${PATH}
and I make a symbolic link /opt/texbin pointing to the most recent TeX Live I have on the machine, by doing
sudo rm /opt/texbin
sudo ln -s /usr/local/texlive/2015/bin/x86_64-linux /opt/texbin
In this way echo $PATH will show something like
/opt/texbin:...:/usr/bin:...
provided no later file in /etc/profile.d adds something in front of PATH. The important thing is that /opt/texbin is before /usr/bin.
At a new release of TeX Live you just have to reset the symbolic link and do nothing else: the GUI programs and the shell will find the correct binaries. But, as seen above, you can still run the programs in other TeX distributions.
Remember: when you install a vanilla TeX Live, never set the option “Create symlink in system directories” to “Yes”. Be sure it's set to “No”, particularly on GNU/Linux systems, where a distribution provided TeX Live would take over in case of upgrades.
Best Answer
What you want is possible to achieve with TeX Live to some extent, but there are some caveats. People often want multi-OS setup on a network share and this is well supported. On a USB stick things are more complicated, because of symlinks which are not supported on Windows file systems[*] (FAT32 is the one usually found on USB sticks).
One way around it is to install with
--portableoption, add any platforms you require afterwards (Windows, OS X, etc.; this can be done only when installed on a Unix-like OS, again, due to symlinks problem), and finally copy everything to a USB stick with dereferencing symlinks to copy the linked files instead.You won't be able to update such an installation afterwards, though (or to be more specific, updates of binary packages with symlinks won't work[*]). However, binaries are usually not updated between yearly releases, so you might in fact get away with this, but there is no guarantee [**].
A possible further hack would be to remove all platforms but the Windows one, but only from the TL database and not their actual files, so tlmgr is effectively fooled and won't do any updates to the "problematic" packages. Such a setup may be fragile under certain circumstances [**] and requires hand-editing of TL database, which I don't recommend to anyone unless they know exactly what they are doing and can recover from possible breakage.
Yet another approach to updateable system on a stick could be to keep updating the original "source" installation and sync it with the USB one afterwards, which is a bit less convenient and also means no updates on the go, but OTOH shouldn't cause any problems (the last famous words).
[*] Edit: To clarify the issue with symlinks - TL packages are stored simply as compressed tar archives (+ some meta data about the package). Symlinks are archived together with regular files and everything is extracted during package installation and/or update. If the file system doesn't support symlinks, this extraction will fail and therefore package installation/update will fail.
[**] Edit 2: TL makes package backup before its update, so update failure should not be fatal (the old version will be restored), but this can be fragile if the old version has some incompatibility with dependent packages.