As a solution to problem 1 you should involve the customer in the process. As a part of scrum, every sprint has a sprint review which consists of two parts: one where you show the client the result of what has been done and one where the team reviews the sprint to see what went well and what needs to be improved (aka the retrospective).
The sales department should be very clear towards the customer that the deadline is an estimate and that the customer will be made a part of the process, giving them incremental demonstrations of the work that is being done so that they can give feedback along the way. If you have a client that doesn't want to be a part of the process, solving problem 1 becomes almost impossible.
Also, as long as the sales department keeps making promises that are highly improbable to be kept, the company image will suffer. They must be made to realise that it's better to have a later deadline and sometimes be done with the work before that than it is to promise a sooner deadline and have to buy more time with excuses or limit the scope of the project to be able to make the deadline.
Ideally, the team should get a hand in setting the deadline: first the sales team gets the requirements from the customer, then the team turns those requirements into stories and tasks and makes a rough estimation of how much time it will take to complete them and finally you and/or the sales team adds a few sprints worth of time to that estimate to determine the deadline for the customer. If the team doesn't consist entirely of people who are fresh out of school, their experience (whether in the current team or another team) should help them make this very rough estimate and if the team stays together they will keep getting better at it.
As you can glean from my solution to problem 1, I don't entirely agree.
The start of the process in agile is to determine what the customer's needs are and defining those at a high level. As soon as this is done, one should work with the customer to break up the high level chunks into more concrete parts and the priority of those concrete parts should be determined.
Based on this information, the team can make a more concrete estimation of the work that will be required to satisfy the stories and on that estimate, you can base a roadmap: figure out the interdependencies, combine them with the priorities worked out with the customer and now you can define a general roadmap. This roadmap won't survive reality, but it should be a good indication.
Note that sometimes, the customer will insist that everything is of equal priority, they need it all done by the deadline. This is never true: surely in a spreadsheet app the ability for the app to make calculations is more important than the ability for the user to have a colour picker to make the cells in the table turn that colour.
In general, remember the project management triangle!
If the project is fixed price, the deadline is fixed and the scope is fixed, the only thing left that can vary is the quality. If the customer wants a high quality product, you need to have flexibility on at least one point: cost, schedule or scope. This triangle has proven itself time and time again, pretending it doesn't hold true for your company is an illusion. Help your sales team understand this, work together to establish a process that works for the company and is acceptable for the customers. Inevitably you will lose some potential customers over this, but consider that it would most likely have been impossible to satisfy them to begin with. Rather than risking the company's good name (and the potential resources needed to complete the product before the deadline at all cost...) it is preferable to work with customers that can understand the reality of software development.