As it goes, the answer to "how do you eat an elephant" reads "one bite at a time." And a lot of agile folks subscribe to that notion in general—you can accomplish any task if you break it up into smaller tasks, and take it one small bit at a time.
Problem is, that doesn't really work. Once more, it comes down to context (you knew I'd drag that in somehow, right?) There's a great example of this in the new book The Agile Samurai. One of the examples on estimation starts off asking how long it will take you to eat a cookie. Based on that, how long will it take you to eat 7 cookies? 14? How about 200?
Context obviously matters: the state of the system initially is not the same as the state of the system after eating 20 cookies (believe me, I've been there). It's non-linear: input to the system changes the system itself, and it's capacity, and eventually its desire to ever see another cookie again.
So no, "one bite at a time" is the wrong answer. It's not sustainable. Instead, the first defense against "How do you eat an elephant?" is to ask the clarifying question, "WHY ARE YOU EATING AN ELEPHANT???"
Too often, even on agile projects, we take whatever absurd requirement is handed to us and fire up the story cards and the burndown charts and get cracking on it. It would be a nice first step to dig into the absurdity first, and see why we think we need to make elephant kabobs. Maybe the real requirement was misheard, and they actually said "add a font and some knobs"
But it is incumbent upon you to ask. And if the person you ask replies with "because they told us to" (or something similarly Nuremberg-esque), go up one and keep asking.
And if it turns out that you do, in fact, need to eat an elephant, then you're going to need a lot of friends. Or a lot of Tupperware.