You cannot set aliases in the target repo's configuration merely as an automatic result of cloning. Such a feature would be open to pretty wild abuse, since it would mean that I could trick you into running arbitrary code of my choosing by getting you to clone my repo and having it set an alias you don't expect over a command you're likely to use.
"But, Mark, aliases can't override built-in git commands."
Ok, but if I'm trying to propagate some sort of malware, I probably only have to fool some of the people some of the time. A lot of people have a "co" alias, or struggle with typing "chekcout" when they mean "checkout"; so I can alias things like that. You probably don't want to blindly accept those configurations from any old clone
operation you might execute.
You can create a script that sets the alias configurations and include it in your repo. Then someone who clones the repo can run the script (if they trust you, or have examined the script and are satisfied that it's safe).
For a trusted repo, you could even set up a hook to run on checkout or something, so that the alias configuration can be updated as the repo content changes. Again it would be up to the local user whether to actually configure this hook or not, as is necessary for security.