I would recommend a quick read through the manual chaper on overlays. Overlays provide package definitions that layer on top of an imported nixpkgs. So, they themselves don’t pin a nixpkgs (though some overlay authors will pre-build their packages ontop of popular nixpkgs channels to pre-populate binary caches for users).
In the example that I’m giving, we’re importing our own specific version of nixpkgs, and explicitly applying a specific version of the overlay. In this way, the local configuration (~/.config/nixpkgs/...) is completely ignored, so there’s no need to be concerned about what state they are in. But this is only valid in the scope of that file.
If you really need this to apply user-wide, then my example is only partially applicable, and you have gotten the important part.
Something like what you showed should work for overiding specific packages to come from the specified pinned nixpkgs. However, since overlays are a different beast, they look different. And when you specify overlays in ~/.config/nixpkgs/overlays/..., the nix file would just return the result of the fetchTarball (or whatever file from the overlay contains the actual overlay function. Sometimes that’s the default.nix, sometimes that’s an overlay.nix.)