That trick of course, is what agile methods are all about. An agile process gets out of the way so you can translate a software need to actual software rapidly. This gives you short periods of clarity that can be repeated to spiral in on what you really need.
If you are using short iterations in an agile methodology, I think that everything here still applies, but at two separate levels. First, my opinion is that you still need an opening phase at the beginning of a release cycle to set the overall direction (others may not agree). You may choose to just map out a series of features (*cough* stories) and their initial ordering. Second, you still need to do some form of planning and design in each iteration that will look very similar to the opening phase, just in compressed form.
1 If the engineering team is being handed both dates and a feature list then the only variable they can affect is quality, and it’s gonna be bad. It’s your responsibility as an engineering team to push back if this happens to you. My experience has usually been that there is some way to compromise if everyone goes into the discussion with the idea that there is actually a compromise. Sometimes that means looking at whether the parts of a feature that are most costly to build are the most important to the business. If not, you might be able to pare down a feature or come up with some way to stage the feature.
3 By the way, I find a release with 4-6 weeks of dev is what I like the best. I can hold the schedule outline in my head for something scoped to that size. I expect to spend at least 2 weeks of that period doing planning and design. Realistically the planning lasts longer as a few people may start the process before the prior release is out and/or may bleed late for a subset of the features.