There's no need to change the manifest to point to your Git server. The .. URL that's in the android-4.3_r2.1 manifest means that the git URLs will be relative to the manifest's URL. In other words, if you clone the manifest from your local mirror the remaining gits will also be fetched from your local mirror.
When you're talking about vendor and master branches I'm assuming you're talking about local branches (i.e. visible in the git branch output). In this answer I'm going to ignore those and only talk about branches on the remote. They're the ones that matter. With Repo you don't get any local branches by default and the name of any local branches is up to every individual.
I'm pretty sure every single one of your projects have a master branch – on the "aosp" remote. I suggest you pick another branch name for your adaptations and the patches you get from your vendor. In fact, it's wise to choose a different namespace altogether. If your company or organization is named Acme you can place all your branches under acme/, so acme/master, acme/vendor, and so on. (I prefer doing it the other way around, i.e. stuffing the upstream branches into separate namespaces, like aosp/ and caf/. That way the branches that you actually work on don't have a prefix and you can have multiple upstreams.)
Getting all this into a working repository will involve updating the manifest to point to the branches on which you're working. If you push your local vendor branch to acme/vendor, then the manifest should point to acme/vendor. It's up to you whether to create an acme/vendor branch in every single git and change the default revision in the manifest or if you want to push the branch only where it actually needs to exist and selectively override the revision for those gits.
The latter obviously requires you to update the manifest every time you branch a git. On the other hand you won't be littering all gits with unnecessary branches, and you can quickly glance over the manifest file and see which gits are branches and which ones come straight from the upstream. Also, grabbing a new release from the upstream will likely require more work if you branch all gits. Keep in mind that the upstream might switch to another branch for a git so you may get non-fast forward updates even for gits that you haven't touched. The example below shows how how can't update acme/master from 1.2.3 to 1.2.4 as a fast forward, so you'll either have to make a non-fast forward update (generally not recommended), merge from 1.2.3 into acme/master (possible resulting and conflicts and forever making fast forward updates impossible), or create a new branch based off of 1.2.4.
-----1.2.3 (acme/master) -----1.2.4
/ /
------------------------------------
Don't forget to branch the manifest. Repo handles the manifest git in a special way where it assumes that all changes are made on the branch named "default". So, just edit the manifest file, commit your changes, and push it with e.g. git push origin HEAD:refs/heads/acme/master. After that you can initialize a new workspace with repo init -u ... -b acme/master.
Yes, repo upload is for use with Gerrit, which you certainly don't need (though I recommend it for its code review features). You can just push with Git like you normally would do. I see you've already found the repo forall command which is quite useful.
