Entity Framework: Business Objects different from Tables?

How are these audit columns utilised, are they populated by update/insert triggers, and if so, from where is the user context being obtained?  If your app will in any way be responsible for updating these columns, then you will want them in your entities.  If they are set by triggers, you can set the StoreGeneratedPattern property in the model to Computed, this will retrieve the generated value for you on saves (note here there is a well known EF bug with the designer not saving storegeneratedpattern values in the SSDL).
If you don't need to set or retrieve values for these columns at all from your app, then as stated above, delete them from the model, but again ensure you have default values.

Really, you usually don't want your Entities to mirror tables... unless what you're working on is very simple...

Also, I personally wouldn't encourage calling Entities Business Objects.
The Entities should be part of (or most of) the Data Access layer.

Then you can have DTO (POCO) classes to pass between layers.
My personal take on this is that Entities should be concerned with data, and Business Objects should be concerned about application logic... but I'm sure people will disagree.

Yes you can remove it from the entity model.  Just ensure these things have default values assigned so, that inserts won't conflict.  You can mark the specific property as private using the properties pane in the EDMX designer.