I agree that we should figure out the right UX here. And @pradyunsg’s options seem about right.
However, I think there’s another (less UX-focused) aspect to consider, which is whether we put the build logic into “the tool”, or do what we’ve been trying to do in other areas, which is to make a reusable library, and then simply call that library from the “official” tool. That would probably mean putting work into making pep517 more robust and complete, and in particular making it the canonical place where “setting up a build environment” logic is implemented.
This I disagree with. If you’re doing <whatever tool> build foo, you could quite easily be building a wheel for foo to be used across multiple machines, possibly via multiple installers. So it 100% shouldn’t matter what installer is used to set up the build environment.
What is important (and I think this is what you were intending) is that the user should have an easy way to configure the options needed for that installer to run, and ideally those options should be automatically picked up from the config options that the user’s “normal” installer uses.
That may mean standardising an “installer configuration” format, or it may mean that the build tool needs a UX to say “use this installer for the build environment”. That’s up for discussion. (And yes, I do anticipate the possibility that if we make pip the build tool, someone will want to do something like pip build foo --isolated-env-installer=poetry… 
)