/usr/, I assume is the user of the computer.
Originally, yes, it did refer to the system's users. Before AT&T changed the default location for user folders to /home in System V Release 4 (SVR4), the default was /usr. That is to say, your $HOME might have been /usr/jfw on a System III box. (Other schemes also existed in the past.) /usr also contained, then as now, /usr/bin, /usr/lib, etc. Experience showed that segregating the home directories was good system management practice, so the default was changed, leaving behind everything we now think of as belonging in /usr.
The best reason for /usr to still be called that is that it contains "user files", which is to say things that don't need to be available until the system has booted up far enough to support normal use by users.
There's a clear dividing line: a Unix box is supposed to be able to boot up into single-user mode without needing any file under /usr. You can try it on your Mac, if you like: hold Cmd-S while it boots, and you will land in single-user mode. It's like running under the Terminal, but it takes over the whole screen because the GUI hasn't started yet, and you're running as root. (Type "exit" at the single-user root prompt to leave single-user mode and continue booting into multi-user mode.)
Unix systems are organized in this fashion because Unix dates from the days of 5 MB hard disks the size of washing machines. It was common for a big Unix system to have multiple physical hard disks, and for /usr to be off on a separate disk from the system's boot volume. If the /usr volume wouldn't mount for some reason, you could still get a Unix box to boot up into single-user mode to fix it.
.../local/...obviously stands for the local computer...
Yes. It refers to the fact that files under /usr/local are supposed to be particular to that single system. Files that are in any way generic are supposed to live elsewhere.
This also has roots in the way Unix systems were commonly used decades ago when all this was standardized. In this case, it's again because hard disks were bulky, really expensive, and stored little by today's standards. To save money and space on disks, a computer lab full of Unix boxes would often share most of /usr over NFS or some other network file sharing protocol, so each box didn't have to have its own redundant copy. (This is also where we get /usr/share: it segregates files that could be shared even between Unix boxes with different processor types. Typically, text files: man pages, the dictionary, etc.) Files specific to a single box would go under /usr/local, which would be a separate volume from /usr.
This historical heritage is why it's still the default for most third-party Unix software to install into /usr/local when installed by hand. Most such software will let you install the package somewhere else, but by making a non-choice, you get the safe default, which doesn't interfere with other common install locations with more specific purposes.
There are good reasons to make software install somewhere else instead. Apple's OS X team does this when they build, say, grep from the GNU grep source code. They use /usr as the installation prefix, overriding the /usr/local default. Another common prefix is /usr/X11R6.
And what is /bin?
It's short for "binary", a generic term that can refer to many different things, depending on context.
In the context of Unix directories, it refers to that fact that the files in that directory are compiled executable programs, as opposed to text files, which live elsewhere. Some Unix people call executables "binaries" for the same reason.
On a modern system, it's common to find the occasional script file in a bin directory. That bends the original meaning behind the purpose of this directory, since scripts are text files, but it's not a problem in practice. The original Unix systems were carefully enough scoped that this didn't happen, at least not with the OS as originally delivered. Scripts that came with the OS lived elsewhere, like /etc.
