For pages in the menu aka CMS pages, yes, canonical url is set in code behind of Default.aspx.cs like this:
if ((Page.Header != null)&& (CurrentPage.UseUrl) && (CurrentPage.Url.Length > 0))
string urlToUse = SiteRoot + CurrentPage.Url.Replace("~/", "/");
if (CurrentPage.CanonicalOverride.Length > 0)
urlToUse = CurrentPage.CanonicalOverride;
Literal link = new Literal();
link.ID = "pageurl";
link.Text = "\n<link rel='canonical' href='"
+ "' />";
for supporting pages it is up to each developer to add canonical url using their own code, so yes you would need to add your own logic similar to above in your custom code.
The purpose of passing the pageid and module id is both to keep the menu highlighted for the current page, to be able to link back to the current page, and to be able to enforce page and module view/edit permissions in your supporting page. There are helper methods in mojoBasePage you can call to check permissions with the module and page id
if you maintain pageid and moduleid some other way it still will not highlight the menu correctly if pageid is no in the url. When you are on a cms page with a friendly url, the friendly url is already really mapping to a real url /Default.aspx?pageid=x but you don't see this because of url re-writing. But once you navigate to a non cms page the pageid must be passed in order to have the menu highlighted and also to have a CurrentPage object that is correct. Also if search engines don't have the pageid or moduleid in the url then if a user clicks the search result there will be nothing already in sessions so there will be no way to determine the page or module.
The other alternative is to implement friendly urls in your custom feature that link to a detail page, similar to what we have in the blog or webstore. For example in WebStore we have links to product detail page using friendly urls like /productname.aspx, but it maps to a real url /WebStore/ProductDetail.aspx?pageid=x&mid=y&product=z but because we use friendly urls with url rewriting the user does not see the paramters they see the friendly url /productname.aspx
You could study existing features like blog and webstore to learn how to implement friendly urls in your own feature. Friendly urls are even better for SEO because they can have key words in them as compared to some number identifier in a parameter. So if I have a product url like /panasonic-bluray-dvd-player.aspx that will be a better url than /productdetail.aspx?item=x in terms of SEO because the url indicates and re-enforces what the content on the page is.
Hope it helps,