Other answers have given all the good choices, but without much description. Here's some more detail:
DrRacket
Racket's IDE, DrRacket, is a great tool for beginners and has a lot of strengths for more advanced schemers. It has good profiler and debugger support (far better than Emacs), uses "standard" keyboard shortcuts by default, and is very clean and easy to use. However, it sometimes lacks functionality its creators view as confusing; for example, compiling only some expressions from your source code can put the REPL in a confusing state, so it's not provided. DrRacket only works for the Racket dialect of Scheme and its derivatives, however, so if you want to work with another implementation, you should probably look at:
Emacs
GNU Emacs is another fine option for advanced schemers who are willing to put some time into learning their editor. It is powerfully customizable, has modes for almost any file type, and handles Scheme well, especially with quack installed (quack is an extension for Scheme named in parody of DrRacket --- get it, quack?). It doesn't limit you from doing anything you might choose. However, it has a learning curve like a brick wall --- its model of text is unique, its keyboard shortcuts are different than anything you've used before (unless you use CUA mode, which makes them more normal), and you have to use Emacs Lisp to configure and extend it.
Bottom Line
You'll be happy using either one once you're accustomed to it. Emacs is less limiting, but harder to learn; DrRacket is more limiting, but more able out of the box in some areas and much easier to learn.
This is a bit of a tricky question, since the differences are both technical and (more importantly, in my opinion) cultural. An answer can only ever provide an imprecise, subjective view. This is what I'm going to provide here. For some raw technical details, see the Scheme Wiki.
Scheme is a language built on the principle of providing an elegant, consistent, well thought-through base language substrate which both practical and academic application languages can be built upon.
Rarely will you find someone writing an application in pure R5RS (or R6RS) Scheme, and because of the minimalistic standard, most code is not portable across Scheme implementations. This means that you will have to choose your Scheme implementation carefully, should you want to write some kind of end-user application, because the choice will largely determine what libraries are available to you. On the other hand, the relative freedom in designing the actual application language means that Scheme implementations often provide features unheard of elsewhere; PLT Racket, for example, enables you to make use of static typing and provides a very language-aware IDE.
Interoperability beyond the base language is provided through the community-driven SRFI process, but availability of any given SRFI varies by implementation.
Most Scheme dialects and libraries focus on functional programming idioms like recursion instead of iteration. There are various object systems you can load as libraries when you want to do OOP, but integration with existing code heavily depends on the Scheme dialect and its surrounding culture (Chicken Scheme seems to be more object-oriented than Racket, for instance).
Interactive programming is another point that Scheme subcommunities differ in. MIT Scheme is known for strong interactivitiy support, while PLT Racket feels much more static. In any case, interactive programming does not seem to be a central concern to most Scheme subcommunities, and I have yet to see a programming environment similarly interactive as most Common Lisps'.
Common Lisp is a battle-worn language designed for practical programming. It is full of ugly warts and compatibility hacks -- quite the opposite of Scheme's elegant minimalism. But it is also much more featureful when taken for itself.
Common Lisp has bred a relatively large ecosystem of portable libraries. You can usually switch implementations at any time, even after application deployment, without too much trouble. Overall, Common Lisp is much more uniform than Scheme, and more radical language experiments, if done at all, are usually embedded as a portable library rather than defining a whole new language dialect. Because of this, language extensions tend to be more conservative, but also more combinable (and often optional).
Universally useful language extensions like foreign-function interfaces are not developed through formal means but rely on quasi-standard libraries available on all major Common Lisp implementations.
The language idioms are a wild mixture of functional, imperative, and object-oriented approaches, and in general, Common Lisp feels more like an imperative language than a functional one. It is also extremely dynamic, arguably more so than any of the popular dynamic scripting languages (class redefinition applies to existing instances, for example, and the condition handling system has interactivity built right in), and interactive, exploratory programming is an important part of "the Common Lisp way." This is also reflected in the programming environments available for Common Lisp, practically all of which offer some sort of direct interaction with the running Lisp compiler.
Common Lisp features a built-in object system (CLOS), a condition handling system significantly more powerful than mere exception handling, run-time patchability, and various kinds of built-in data structures and utilites (including the notorious LOOP macro, an iteration sublanguage much too ugly for Scheme but much too useful not to mention, as well as a printf-like formatting mechanism with GOTO support in format strings).
Both because of the image-based, interactive development, and because of the larger language, Lisp implementations are usually less portable across operating systems than Scheme implementations are. Getting a Common Lisp to run on an embedded device is not for the faint of heart, for example. Similarly to the Java Virtual Machine, you also tend to encounter problems on machines where virtual memory is restricted (like OpenVZ-based virtual servers). Scheme implementations, on the other hand, tend to be more compact and portable. The increasing quality of the ECL implementation has mitigated this point somewhat, though its essence is still true.
If you care for commercial support, there are a couple of companies that provide their own Common Lisp implementations including graphical GUI builders, specialized database systems, et cetera.
Summing up, Scheme is a more elegantly designed language. It is primarily a functional language with some dynamic features. Its implementations represent various incompatible dialects with distinctive features. Common Lisp is a fully-fledged, highly dynamic, multi-paradigm language with various ugly but pragmatic features, whose implementations are largely compatible with one another. Scheme dialects tend to be more static and less interactive than Common Lisp; Common Lisp implementations tend to be heavier and trickier to install.
Whichever language you choose, I wish you a lot of fun! :)
Best Answer
The differences between Common Lisp and Scheme are over-rated. They are there, and some are important, but for actual work you will not have any trouble learning one and then the other. When I was commonly writing both, I could switch between them with no problems.
If you plan to start with SICP, then I would start learning Scheme. If you plan to start with your project and decide that you need Common Lisp for it, then I would start learning Common Lisp. Learning the second dialect is very easy after that.
There are a couple of things to consider. The type of project is most important: Scheme is excellent for language design projects. If your project is an interpreter/compiler/parser/etc for a new, weird kind of language (or just language feature), then Scheme is ideal. On the other hand, Common Lisp is very powerful in areas where you need a lot of basic utilities already built-in, but don't know precisely what it is you are building ahead of time--you end up with a DSL most of the time. That's why it was so popular in artificial intelligence. (That's the kind of code that I used it for.)
Second is that PLT has a low-learning-curve Scheme IDE called DrScheme. Common Lisp has a high-learning-curve Emacs plugin called Slime. In my experience, Slime is more powerful, but there is enough learning required that you should probably take it into account if this is a semester-long project (especially if you don't already use Emacs).