1) Yeah, if the "make install" target (or other way of installation) copied the needed files to your system directories - this is mostly true, but some projects might just build one executable in that directory which you need to move away yourself; I recall ufraw was one of them. So most of the time it's "safe" to remove the source directory. But remember that along it you delete the generated configuration and such.
2) The README and/or INSTALL files should tell you how, if it's possible. There's no rule that says the project needs a way of removing the installed files, so it's up to the software maker to create one or then not. Typically a source project is first compiled (source => binary), then "installed", which actually means just copying the binaries to the right directories on the system, documentation to their own directories etc. etc., depending on what the project consists of. So "removing the installation" means just the opposite: deleting the copied files, and undoing any changes to configurations that were done. Many projects that you can build with make (i.e. they come with a Makefile) do contain an uninstallation target, so running "make uninstall" will remove the "installed" files. Inspect the Makefile for more information and read README and INSTALL files.
3) The compilation process does not need root privileges until you do something that requires root privileges - typically this happens when you need to copy files to directories that users can read but not write to. If the installation steps for example copies a binary to some bin/ directory and you don't have write permissions there, the installation step fails unless you run it as root. If it only copies files to directories where you can write, then it may succeed, but as far as I know, for system-wide (i.e. for all users, not just you) installations the actual "install" step is recommended to be run with root privileges.
About the removing, there are some programs that are specialized in that: instead of executing the "make install" command you execute a program that in turn executes the real installation command and then inspects what files were copied where, makes notes of them, and later when you want to remove the program, you ask this "3rd party" program to remove it, and then it just removes the files it got up. There are many ways how this is achieved: one is that the "manager" program makes the program install itself into a subdirectory inside the build directory, where a directory tree is created that matches the system directories (like source/usr/bin/, source/bin, source/usr/local etc.) - then it saves the file locations to some sort of database and copies that directory recursively to filesystems, thus putting the files into their correct places (this is a simple explanation for such a system, and there are a lot of other ways of doing it - package management is a wide thing, if you start reading about it).
Also note that if you want to use "make uninstall" and remove the source/build directory, you need to unpack it again, reconfigure (./configure -step, remember?) the source in the same way you configured it when installing, and then run "make uninstall" to remove the already installed program. Reconfiguring the source is wise, because if you used some sort of prefix during installation (for example) and later don't set that same prefix, the "uninstall" target probably either fails or even removes wrong files.
The easiest way of installing software nowadays is using a package manager such as apt(-get) or yum if the distribution has one - and if you have the packages available (.deb, .rpm, you name it). Though sometimes it's just easier to install from source - or then it's the only way - and in that case you have to take care of installing, updating and removing of the software completely yourself (or use some software that [semi-]automates this for you) - the software can include some automatic things such as scripts for installing, compiling and/or removing the software, but in the end it's you, the system administrator, that needs to verify how things work and what is the right course of action.