+1 to @thonnor's suggestion of allowing a POC, and @stefan's observation that past experience is not always a predictor of future performance. I would try to approach the problem a bit more econometrically, like so:
If you had no other projects to work on, then you should let your team try The New Thing. Obviously, part of the problem is that you do have other projects to work on. Presumably, folks have given some thought as to how much value those other projects have. If The New Thing works out the way the team expects, then perhaps it should move to the front of the queue and be the first priority. But there is great uncertainty in the probability of success, and your "prior distribution" (to use a Bayesian concept) for The New Thing is low, based on your experience, while the team believes it is average to high, based on perhaps no experience.
Let's Make A Deal
The fair approach, IMO, is to gamble. In particular, engage in a game of chance with your team. The contest is to create a successful PoC. You and the team agree to a set of "success criteria" that will determine whether everyone agrees that it has good potential and has passed the blockers that you think will cause it to ultimately fail. Now, create a bucket of time, which is the only resource of intrinsic value, that we call "the bankroll". This is the total amount of time that your "organization" (the most self-contained portion of your org chart containing your team) is willing to spend on "bottom-up" projects (vs. the the default "top-down" projects) for the quarter/year (pick an appropriate time horizon).
The bet works as follows: the team can spend as many hours from the bankroll as they think they need to bet on their deliverables. If, after the agreed delivery date, everyone agrees that the deliverables have been met, then they get their "bet" back, which gives them "funding" to continue to develop their POC. Otherwise, they "lose" their bet, and they can decide whether to continue chasing it, spending down their whole bankroll until they are forced to quit, or to give up and wait for a better bet to place.
In this game, you represent "the house", and your role is to demand as much from each deliverable stage as you think is appropriate given the amount of risk/reward and the time being spent. Note that this does not mean you should push for the team to promise unrealistic deliverables. You should, in fact, treat the project like any other. If the team says: "Over the next two weeks, we want to bet 50 person-hours on The New Thing", then you should scale the deliverables to be equivalent in value to 50 hours of the top project in the queue. If they protest, just point out how you arrived at your valuation, and negotiate until everyone agrees on a bet that is fair.
Naturally, these valuations are subjective, but hopefully everyone can come to a ballpark agreement. For you, the thought process should be: "What would I have to show stakeholders instead of the normally promised deliverables that would still make them happy?" Obviously, the team is constrained by what they think they can deliver on time, and part of the challenge is to make the PoC small enough to succeed, but big enough to demonstrate value, even if they have to deliver it in several stages.
Also, it might help if you simply pitch the idea directly to stakeholders, so the team sees what kind of push-back you are likely to get. "Dear Stakeholders, The Team would like to try building a PoC for The New Thing over the next 2 weeks. We think it will provide X, Y, and Z, which compare favorably to Milestone N on Top Project. What is your feedback?" If the stakeholders say: "Yeah, we tried something like that before, and it failed because nobody wants to adopt a new process", then the team can see that their idea has cultural challenges in addition to technical ones. If the stakeholders say: "Yeah, that sounds like a good bet" then perhaps the broader support for the idea will help it succeed.