These are called "spikes" in the agile community (no idea why), and "prototypes" elsewhere.
If you feel that the error bars are too wide on your estimate, you should build the minimum prototype required to reduce the uncertainty to tolerable levels.
I like to schedule these at least a sprint prior to kicking off the main task, so that you can benefit from the improved estimate accuracy when actually scheduling the thing.
The analogy I've been using lately is that it's like estimating how long it will take to pack your kitchen when you are moving, except sometimes you open a cupboard door and there's another kitchen inside.
That´s not necessarily true. I´ve worked with very good, serious consultancies, and I´ve seen a quote for thousands of dollars for exploratory work to give an estimate. Of course that was for a million dollar project - smaller projects might not have this opportunity.
Other companies had some interesting approaches where they gave order-of-magnitude estimates and then refined the estimate iteratively.
They don't assume it's the starter and tell you it will be $400 for parts and labor. They tell you it will be $150 diagnostic fee and the diagnostic will take two hours. Then they call you and tell you the cost to fix and time it will take.
For whatever reason, software engineers don't have the luxury of doing a diagnostic. We are made to guess up front and assume it's the starter, when we really have no idea what rat's nest is under the hood until we look.