(Note: I'm still learning git myself, so I could be completely wrong about, well, everything.)
Is there a way to make new branches without inheriting commit history…
If you don't inherit the commit history, it's not a branch, is it? I mean, the "branch" metaphor comes from the idea of a collection of serially-connected former "current states" of the files in the repository, so without a commit history, what would the current "current state" be a branch from?
I know what you really meant—how to only "not inherit" the messy parts of the history —but if you take it to the extreme, it's easier to see the problem.
how can we merge/squash our dev branches into occasional single-commits in our release branch?
You can squash commits using an interactive rebase: "rebase -i [commit-ID]".
But doing that will squash the commit history of everything. Because a branch only has an independent commit history while it's branched (i.e., unmerged), and that history only goes back to when it was branched (or to the most recent merging).
So, it seems to me, you're doing your branches the wrong way. Or, rather, you're thinking about them in the wrong way.
Your "release" branch should be the main commit history. You then branch off a "master-development" branch from the "release" branch (conceptually, if not literally). You then branch feature-development branches off of the "master-development" branch. And then various working branches from the "feature-development" branches, which is where you make your ugly flurry of commits.
You then rebase those working branches to have clean commit histories. Merge the now-clean working branch into the "feature-development" branch, and so on up the tree. By the time you're merging into the "release" branch, the commit history is well populated with succinct, logical commits showing the progress from the previous version to the now current one.
Or not. As I said, I'm still learning git, and the commit histories on my repos are nightmares. So, that's all just speculation, not experience.