On my website I have a password reset page that users can use if they have forgotten their password. On this page they can enter their username or their email address and hit "reset" which will send them a link to reset their password.
If they have entered an incorrect username or email, should I let them know that it does not exist in our system, or is that a security risk?
The answer is generally it depends. This is really based on the security of your system.
Users can create new accounts without restriction
If so, it is kind of meaningless to not tell them. You can't have intersecting usernames or email addresses, so you have to inform a new user if their username or email has already been used. An attacker would then be able to obtain the usernames and emails by attacking the new user registration system. Giving them a similar venue to attack in the forgot password section does not harm your security any because the method just exists elsewhere. Just make sure that the restrictions you use in the registration system are the same as the restrictions for requesting a password (that is whatever anti-spam system you use).
Users cannot create new accounts without restriction
Consider an invite only system. The only way you are allowed to register is if someone has authorized it. This could be an instance where an administrator sets your initial username, email, and password (potentially manually). This system would allow you to gain security by not telling users if their entered information is correct or not. Usernames and emails could then be treated as a weakly guarded secret.
Overall
Note that this is a hit to usability. If someone mistypes their email address, they may not notice that they did. Emails from websites don't always come through immediately, so a user could be waiting for an email that never comes.
There is an old tradition of not distinguishing between "that username does not exist" and "that username exists but the password is wrong". It comes from older times, when both attackers and defenders were new at the job, and the context was different. At that time, the attacker was "outside" and he wanted to guess a username+password pair in order to enter the mainframe. At that time, passwords were even poorer than nowadays, and it was believed that keeping user names secret would substantially help ("the attacker will never guess that we have a user named 'smith' !").
An interesting reading is this description of the 1988 "Morris" worm. That beast took down the whole Internet (it was smaller than nowadays) by the sheer bandwidth consumed by all the worm instances madly replicating without control. The worm could enter systems through various methods, one of which being password cracking. Interestingly, the worm first collects account names from various sources, including ".forward" files, then (and only then) tries a dictionary of 432 words. This illustrates two points:
Account names are not secret. They don't exist only on the target system; they can also be inferred from various data elements on other machines, including (in modern times) SSH config files, address books,...
Back in 1988 they were really bad at choosing strong passwords.
Times have changed. In particular, as others have pointed out, many modern systems allow for automatic registration: anybody can try to log in, and see for himself whether a given account name is "free" or not. A lot of other target systems allow for account name collection (e.g. Web forums may use the contributor's pseudo as account name). This makes reliance on the secrecy of user names flimsier than ever. On the other hand, one may hope that average users now choose stronger passwords (thinking otherwise would be too depressing). The net effect is a change of balance: the tradition of keeping account names secret has lost most of its relevance.
However, traditions are strong forces. If your system returns the error "that username does not exist" and a different message for "your password is incorrect", then chances are that some users will feel nervous, and scandalized, and will bug you with complaints about your irresponsibility in divulging to the world at large that the name of Joe is Joe. You may argue and offer rational reasons why this is not a problem (see above); some will remain unconvinced. This is not a good thing when the users are customers; and, in any case, this consumes too much time. It is easier to maintain the old Tradition, even if it does not make actual sense; you can view it as a way to cope with the basic irrationality of human users.
No, you should not let them know if the username doesn't exist as it would let an attacker discover account names which they could then attempt to crack. If you send a generic "A reset email has been sent, please check your inbox." even when the account doesn't exist an attacker gains gives nothing from trying.
What matters the most in terms of security is what does an attacker gain from knowing whether a specific ID or email address has an account with your site?
For instance, if you're doing any kind of business that can be seen as a privacy issue, or whether accounts on your site can be used to spend money or have any intrinsic value (in other words whether I can gain something from phishing your site). Some sites don't have this kind of issue, for instance a micro-blogging platform or OSN would display your ID on your page anyway, so letting a user know they typed an unexisting ID can be useful.
From a usability perspective, not telling your user if their ID exists is disastrous. Any website that uses IDs should at least confirm an ID (IDs are specific to your site so they don't provide spammers much information). Not telling your user the email address also is a terrible idea: they need to retype every possible password they've used for each of their email addresses.
Ask yourself how often your users visit your website. A low frequency of visits will greatly amplify usability issues, to the point where you might want to enable one-time passwords sent via text or email instead of a traditional login form, for anyone connecting only a few times a year.
For instance, I have two different addresses at work, multiple passwords for different subsystems and an idiotic password reset policy, on top of which I have my personal email address and a ton of different passwords. It can take tens of attempts to find the right email/password combination for a site I don't often go to.
As pointed out by @William Forcier, you can gain knowledge of whether an email is in use by several means:
You could still deploy different defenses for each form though. If you decide that you should absolutely hide email addresses, then you can just block/complicate (CAPTCHAs) account creation to a specific IP address after a too large number of creations. You'll probably need a mechanism to protect against spammy accounts anyway (but remember not to ruin the life of your actual users by unusable solutions, for instance systematically serving CAPTCHAs).
One aspect I have not seen mentioned is the fact that many login difficulties arise because a user's preferred name was taken before he tried to register for a given site. If "JSmith" tries to log in and can't, what he really wants to know is not whether the site has an account named "JSmith", but rather whether the site has an account for him named JSmith. If the site has some public information associated with users (e.g. an avatar picture), and allows such information to be freely queried, then it may be helpful to not only indicate whether an account exists for JSmith, but also show some information associated with it. If Jack Smith always uses a cat as an avatar, and when he tries to log in under JSmith he is shown a dog, he would know that the problem isn't a forgotten password, and he should thus try one of his "fallback" user names rather than a "forgot password" link.
