There is a lot of nuance to this question so its taken me a while to answer it. First let me address the main question. It sounds like you would like to have more than one user making blog posts in the same blog and having it show who the user was at each post. I will look into making this possible in the blog as soon as I get a chance.
In general, I do not want to encourage people to just start hacking away at the mojoPortal code to make customizations. Doing so can make it impossible for you to get upgrades without losing your customization. I just wrote a new article Cloning an Existing Feature, to address this. By first cloning a feature, you can then safely make customizations to your cloned copy without losing the ability to get upgrades.
So this connects with your question about API documentation. At one level publishing an API document might encourage people to code against the API when really there is very limited API that I really think should be coded against. There are definitely useful things to be familiar with like SiteSettings, SiteUser, SiteUtils, WebUser.IsInRole(s), but there are a lot of things like individual features such as the blog that I don't recommend coding against.
In general my suggestion is to read the code, it is the best documentation and you can find example code for doing just about anything you might need.
With that said, its not like I'm opposed to producing an API document. The back story on that is that once upon a time I started working with NDoc to automatically generate API documentation. But we have not done a great job with the xml comments to produce a very nice result. I've inappropriately used the <summary section to put license information and a lot of this kind of thing would need to be cleaned up to get nice results and more explantory summaries would be helpful. So just when I started looking into it is when it was time to go to VS 2005 and for a while there wasn't a version of NDoc for it, then finally one was available but soon after it was time to go to VS 2008 and now there is no NDoc for VS 2008. I did recently find that Sandcastle is the new thing for this and the Sandcastle Help file builder. So I have actually generated an MSDN style API document in the form of a .chm file. but again the output leaves much to be desired because we have not made the best use of the xml commenting. It will be a gradual process of fixing the summaries on the most important classes/methods first to get to a really nice output generated from the code and xml comments. For the moment and probably even after we do have a decent API document, I still think the code is the documentation of first resort.