To answer your question, no, that isn't normal in an Agile process.
Where it may seem to stem from an Agile attitude is from Agile's short-iteration design/develop/test cycle, and Agile's emphasis on lightweight solutions that meet the known requirements, but are well-structured in order to be able to meet new requirements with minimal change. Given these two things, you might say that a developer, not knowing what might come down the line but knowing his change shouldn't impact the DB in a way that can't be undone, simply makes the necessary changes to the schema in the "lightest" way possible, and then at intervals several sets of "light" changes will be refactored into something more permanent and stable.
Having said that, I have not yet worked with a developer who subscribed to Agile theory and methodology, and also thought that routinely creating and deleting tables in the schema was necessary for any reason. Agile doesn't mean slap-dash or bolt-on. If you are given a story that requires the addition of a new field of data belonging to a particular record, you add the field to the table. If that change breaks something, you figure out why, and make other changes as may be necessary (I can think of very few things that would break by adding a column to a DB being queried; if it does break with this kind of change you have bigger problems). Refactoring is normally limited to code; changing the schema is usually a more involved process than changing code, and so when schema changes must occur they are usually made with more care, and at least some attention paid to knowledge of the future direction of the project. Having to re-structure some or all of the database indicates a fundamental failure of design; being Agile doesn't mean there isn't a "master plan" of basic architecture and design rules to follow while organically building the program and data structure.
Now, there are cases in Agile where what you "know" now will be contradicted by what you will learn later. Say you have a requirement that your system must have an Address for every Person. Since this is a 1:1 relationship and the data will be needed in the majority of cases, you simply add the Address fields to the Person table. A week later, you receive a requirement that a Person can have more than one Address. Now it's a 1:N relationship, and to properly model it you must undo your previous changes, splitting the fields out into a new Address table. This is not routine, especially among senior developers. An experienced developer will see that a Person has an Address, consider these as conceptually separate, and create a Person table and an Address table, linking Person to Address with a FK reference to an AddressID. A schema such as this is easier to change should the nature of the relationship change; without creating or deleting entire "wide" data tables, the relationship between Person and Address can be pretty easily modified from 1:1 to 1:N to N:N.