I think this is a very interesting practical question for the experimental sciences. We often have projects that have the need for a bunch of "menial" work (e.g., programming in many of my projects, wet lab work in other fields, ...). I think a lot of the existing answers already highlight important issues (I particularly like Dmitry's), but let me chip in some more thoughts.
I think there are basically two angles you need to think about.
Angle 1: how to explain to students that they can't publish their own work because it will be part of a larger paper, even though they themselves will not be co-authors of said paper
I understand that if this is the situation, it will seem unfair and exploitative to the student. It seems that this is potentially one of these situations that are hard to explain to an "outsider" because, well, they actually are not particularly fair if you consider them from the point of view of the student.
I understand that not every tiny contribution to a project warrants co-authorship. I usually use the metaphor of an open source project to explain this to students - a large open source project like the Linux kernel is a collaboration of many, many people, but only those that contribute significantly enough over a longer period of time get to be maintainers (or co-authors). However (and this part is directly relevant to this question), the individual contributions of each contributor always remain their own "work" - the maintainers can choose whether or not to use them, but they can never pretend that they actually wrote them. Hence, I would urge you to go away from the mindset that the "work of the students is owned by the lab". It isn't. Whatever the student does, it is owned by the student - you can use their work for a publication, but it never becomes "your" work. You didn't do it, and you can't ever pretend you did.
As a direct consequence of this, it is also potentially difficult to prevent students from publishing their own research if the only reason against doing it is that it would hamper your own publication plans. As their work is their work, they should be free to publish it if it is strong enough. Practically, I would strive for a compromise. If your "big" paper is for instance on the analysis of certain data, and the student wrote the tool to collect the data, you can write a tool paper together with the student in parallel or after the submission of the "big" paper. This way nobody can use your tool paper to scoop you on the main paper, and the student still gets his stuff published.
Angle 2: how to decide whether a student should be a co-author?
My simple rule of thumb here is that if the student did anything that shows up in the paper, (s)he is in. To reuse the example of above, if the student wrote a tool to collect data, and the tool is never explained (because it is standard or straight-foward how to do this), I would not make her/him a co-author. If there is a section "Experiment Design" that describes the tool in any length, (s)he is a co-author. Personally, I have a lenient approach to this - if in doubt, make her/him a co-author, maybe under the requirement that (s)he needs to contribute heavily to the rest of the project.
The most important part is to communicate this early - telling a research undergrad that he may be a co-author, and then, after (s)he dilligently did all her/his work, decide against it is a big letdown. Decide when you define the project whether it will be enough for co-authorship and communicate this clearly.
I feel it is also important here to keep in mind that (at least here) many undergrads are "in it for the co-authorship". That is, they are doing free research specifically with the expectation that they will be "paid" in a co-authored paper if the project works out (and good letters, of course). This is another reason to communicate early and honestly with a student - giving a student a project that, even if done nicely, will not be sufficient for co-authorship may be perceived as a "setup" from their side. That is, they may feel that you really just used them as cheap programming labour, without real chance for them to get what they expected out of it. Telling them then about the things they have learned will not smooth things over anymore.