The audit layer will be modeled very closely to the operational support systems that feed data into the data warehouse. Use the Application Triage technique here. Touch an application, take the application. Do change data capture at this level and retain the history, thus you need to add the appropriate metadata to those tables.
The base/history layer should be modeled to reflect the business semantic. Subject-oriented, integrated, very 3NF in design, also some applicable use of Data Vault modeling components to isolate tracking history-sensitive columns and privacy/security-sensitive columns. Use the Table Triage technique here: touch a table, take the table.
The user access layer should be modeled to reflect how the business community uses the information. Lots of dimensional modeling to support functional and performance needs where analytics (score cards, dashboards, loading cubes, etc.) is the need. Also flat "profile" type data sets to support loading up data mining tools such as SAS enterprise miner. User requirements-driven triage here, pull in the data elements necessary to support the information delivery requirements documented.
So the short answer is yes, operational modeling is applicable for certain layers of data architecture within the data warehouse.