Include accelerators, but don’t rely on them
In general, it’s a good idea to try to improve speed of entry (and accessibility) by providing keyboard equivalents for mouse behaviors, especially for something like your form where the user has to use the keyboard anyway. Using Enter to mean OK/Submit is one such example. However, these keys should be considered expert shortcuts due to their poor discoverability. As such, they should never replace the mouse equivalent, only supplement them. This is true even for something as standard/conventional as Enter for OK/Submit.
I'd expect users won't think to try Enter after entering text in each field because Enter usually means "submit all information on this form and take me to the next page (or return me to the origin)." I expect users are not going to want to try that when the form is obviously incomplete. The Tab key usually means "go to next field," and that is the default behavior of the Tab key in most browsers. It's good design to check what you can of each field as the user advances through the form whether it be by Tab or mouse. But you still will need a Submit button at the bottom, because I predict users won't be inclined to tab out of the last field -they won't see a place to tab to.
Why can't you use the Enter key instead of a final Submit-it-all button? Not all users know this standard, and even those that do may not anticipate it being available (especially if this is web app or mobile app, which frequently ignore this convention). You could get a number of users who don’t think to try Enter, and thus flat-out can’t complete the form. Other users will spend many seconds visually searching the form for a Submit button before skeptically trying Enter. You could get angry calls to tech support complaining that “I filled out all the fields with valid data, but the Submit button won’t appear” (the user being a victim of the misuse of dynamically hidden controls from other web forms).
Accelerators have limited value in a use-once form
Due to its poor discoverability, use of Enter, Tab, and other keyboard shortcuts is only likely to yield major benefits for forms each user uses regularly, so users have repeated chances to learn that shortcuts are supported and get use to using them. A user only uses a sign-up form once. I’d still include the Enter shortcut in addition to the Submit button, and be sure your tab order is sensible, but I would expect them to save a small fraction of clicks on average.
The bottom line is time and effort, not clicks per se
Keep in mind that the real usability goal is to minimize task time and effort. Click-counting is merely an indication of the time and effort to do the task. If removing a click adds time and effort in some other way, then it’s no improvement. For example, you could put the text “Or press Enter key” below the Submit button to educate users that Enter is available as a shortcut. Maybe they’ll see it before they take their hands off their keyboards and use it rather than the mouse. On the other hand, reading the text takes time, and now you’ve prompted users to think about whether to use the mouse or keyboard, adding brain CPU cycles that mean more time and effort. Only user testing will tell you if it’s really a net benefit on average.
Meanwhile, there are other places you could reduce time and effort to a greater extent than eliminating one button press. You could combine or eliminate fields to type. JeromeR suggested combining Email and UserID. Or you can combine UserID with Name. Or maybe email alone is sufficient if the only purpose is to identify the account. You could by default not mask the password, if shoulder surfing isn’t a realistic threat (it often isn’t), so user can type their passwords faster and confirm they’re right visually. This might even allow you to eliminate the Confirm Password field. Maybe you can let the user into the app without making them go to their email to click a confirmation link.