If you have a customer that is asking for an estimate, regardless of your estimating process it should be transparent. In other words, whether you're spiking a solution, using historical data, or taking a wild guess, your estimation methodology should be clear to everyone on the team, as well as the Product Owner and the customer.
Estimates Aren't Commitments
Most agile practitioners will recommend that you treat estimates differently than commitments. If you're being asked for a commitment, that's a red flag. Instead, you should estimate by whatever transparent method you can, and then have the project fail early if it turns out that the project can't get where it needs to go.
Use Iteration to Limit Uncertainty
You stated that:
At the moment the developers say they cannot imagine how they would go about implementing some of the features (or if they are even going to be possible)
In other words, your cone of uncertainty for the project as a whole currently approaches infinity. One approach is to estimate a small feature set where the cone of uncertainty is smaller, and then refactor the project estimates, epics, and user stories after each iteration when more is known about the project and its fundamentals.
This is essentially an exploratory approach, but can be viable if the project doesn't allow time for a spike as input to the estimating process. The spike will still need to happen, but will take place within a sprint rather than in preparation for Sprint Planning.
This kind of iterative development will allow the project to fail early when necessary, or to maximize earned value by building only the features that can be built in a cost-effective and timely fashion during the project life-cycle.
Get a Prioritized List
In order to do most of these things, the customer needs to provide the Product Owner with guidance on what's truly essential so that the Product Owner can prioritize a backlog. Once that happens, you can estimate a few of the top stories, rather than the entire product backlog. This is yet another way to limit the cone of uncertainty around your project.
If feature-by-feature delivery holds no value for the customer (e.g. the final product truly has zero earned value unless the entire project is 100% feature-complete) then the customer needs a measure-twice, cut-once methodology that emphasizes detailed planning and work breakdown structures. It may not make their project any more successful, but such a project isn't a good candidate for an iterative approach anyway.
Of course, that said, very few IT projects actually require 100% feature completion. That's why agile projects attempt to make each iteration potentially-shippable: so that the project can be terminated whenever enough value has been realized that further development is not cost-effective.
Root Cause Analysis
All the foregoing is really a way to manage problems that shouldn't exist at the level that it appears to exist in your individual circumstance. In this case, it appears that the problem is caused by faulty communication with the client about process, capabilities, or cost.
If you are in a position to fix the faulty client communications, then you should certainly do so. If you are not, then your professional responsibility is simply to identify the risk to your management team and let them be responsible for the success or failure of the process--they are anyway; it says so in their job descriptions.