I think the goal of what you're trying to achieve is laudable, but extremely complex. While we've mostly been conditioned to think of a package as having a uniform license, there are plenty of examples where code within one package is actually covered by multiple licenses, some less restrictive than others. For example MIT or BSD licensed code re-used and exposed under a project that otherwise generally uses an Apache 2.0 license, or LGPL license.
The reason I'm bringing up this complexity is that I think a better approach for achieving an end goal here would be to leverage a bit of tooling that inspecting existing repositories where code is stored, potentially even reviewing the code itself - which to me seems like it might be a much better fit for a SwiftPM plugin than directly embedded into the manifest and tooling for the package manager itself.
A simple variation of this would be looking for conventional places where license information is stored, such as a LICENSE file in the package's directory (which GitHub did a nice job popularizing and supporting).
If you develop a Swift Package Manager plugin, then you can test everything you want and need entirely locally, as plugins generally are their own packages. That said, the original question was about SwiftPM directly. While it's harder to test that entirely in situ, it's absolutely possible.
As a general tact, I'd recommend starting with using the latest Xcode beta toolchain, which may be using a recent-enough Swift to compile it. From there, you can invoke the binaries directly from their build directory, which has worked reasonable well for me in the past.
I recommend "starting" because in some cases that may not work. Because SwiftPM is compiled in-line with the toolchain, it has (in the past) used features of the language which were ONLY available in the latest main branch of the toolchain, in which case taking the time to download and install a latest toolchain in order to build the package itself would be needed. It's been a while since I've following this myself, so it may not run as "bleeding edge" in terms of Swift language features today as it once did, but it's still worth being aware it's a possibility.
Ole's article on Swift nightly toolchains is an extremely useful primer on how to use a downloaded toolchain effectively, as there's some un-clear quirks on an embedded plist containing information you'll want to know to use it effectively.