Given you’re designing the user interface, not the program’s interface, it makes sense to signal what’s required of the user, not what’s required of the program. Part of the purpose of the UI is to communicate the actions the user can or must make. In the case of require fields, the commonly used red asterisk communicates to the user “you must put something here in order to continue,” not “the software algorithm will encounter a record-not-found error if this field is blank.” With these asterisks, the user can quickly decide if skipping a field is an option. Before submitting, the user can scan the form to check that it is minimally ready, and thus avoid an annoying error message. We use the asterisks because they provide these benefits to the user. Thus, they should be used in a manner that maximizes the benefits for the user.
So, if the field is defaulted and the user cannot blank it (e.g., it’s a drop down or radio button group, not a text box or combo box), then there is no need to mark it required –there is no action “required” by the user. Including the asterisk in this case may draw the user’s eye to the field (as when checking that the form is minimally complete) when it isn’t necessary, adding a bit of workload. That’s not a big deal in most cases, but it’s probably still worth avoiding.
Some might argue that the asterisk encourages the user to check that the default value is correct, but I’m not so sure about that. Communicating “you should check this field is correct” is different from communicating “you must put something (anything) in this field.” I’d argue that generally users have an intuition that computer output is only as accurate as the input, so the fact that the field exists at all adequately communicates “you should check this field is correct.” Your main concern here is users who assume that certain fields are not important (or even unnecessarily prying) due their abuse at the hands of other web sites. User research will tell you if that’s the case, and what you can do about it.