Several questions rolled into one:
Yes you should set a coding challenge, but no, do not set it as homework, for many reasons, some of which are to prevent cheating, copying, plagiarism, getting help. But also because it robs you of two valuable parts: you get to see how their thought process works when under stress, and also (it's a two-way street) they get to see how you approach code development. For example, do you set a slightly ambiguous problem statement and expect them to make simplifying assumptions, or to down tools until you supply a definitive clarification? (the "right" approach depends entirely on your domain e.g. programming life-support systems is different to web code).
I think such an exercise is useful mostly to assess experience rather than ability to learn.
Even more fundamentally, it's to assess the thought process behind the code. Be clear whether you're assessing (algorithmic) knowledge or coding proficiency - those are two distinct things. Tell them you're not waiting to pounce on mistakes, just to see how they approach things.
Do keep it relevant to the job function, but don't ask for free consulting (as @Tim said - this does happen, with sleazy employers). Try to avoid toy problems like FizzBuzz, Towers of Hanoi, Conway's Game of Life. Pick something with more than one algorithmic component to make it immune to simple copy-and-paste.
However, Furthermore, I suspect many junior developers would be terrified at the mere idea of doing a programming exercise for an interview (ever heard of impostor syndrome?), and I'm afraid we'll miss some talent. At the same time we obviously can't afford to hire someone with no experience as a programmer whatsoever, and I'd rather not do whiteboard coding.
Your fears are misplaced. Encourage them to ask questions and/or document assumptions. Tell them it's ok and encouraged to use Google/ StackOverflow/ whatever.
Another good practice sometimes used (esp. on Craigslist or mailing-list/web-based job ads) is to email/post candidates a very simple problem, the solution to which they have to attach to an application. This is to weed out timewasters and people with no interest or experience; but again can be used to give them a flavor of what sort of code they'll have to write.
At the moment I'm considering a mixed solution, i.e. to either require contribution to open source projects, or a GitHub repository, or a Stack Overflow profile; or do a technical challenge.
For people who already have demonstrated proficiency by either of those, then either pick a harder problem, or describe them your problem domain and current issues and jointly define some problem with them - this also gives them insight into the job. (Or you could just ask them the standard question and let them breeze through it or whiteboard describe how to do it, but that's wasting both of your time and not challenging them - Joel and others advise don't.)
And we've found that having candidates code for an hour before interviews helps calm them down and get them in the right frame of mind for questions (often about the coding problems) later.
Yes. As long as you supply the guidelines above about how to approach it and what is being looked for. Not just treat it like some binary pass/fail filter with undefined criteria.